9:50 a.m.
This came up in the review of #293 and I thought that I would bring it
up on the list.
Since our AutoQA server runs RHEL5, it is also running python 2.4 which
doesn't support "finally" blocks.
What is the minimum version of python we want to support? Should all of
our code be 2.4 compatible or just the stuff that will likely run on the
autotest server ( events, watchers etc.)?
We already have several finally blocks in our tests in stable and a
couple in the libs, so breaking 2.4 compatibility wouldn't be a huge
deal in the tests since we haven't seen too many problems so far.
Thoughts?
Tim
10:02 a.m.
On Thu, 2011-04-07 at 08:50 -0600, Tim Flink wrote:
This came up in the review of #293 and I thought that I would bring
it
up on the list.
Since our AutoQA server runs RHEL5, it is also running python 2.4 which
doesn't support "finally" blocks.
What is the minimum version of python we want to support? Should all of
our code be 2.4 compatible or just the stuff that will likely run on the
autotest server ( events, watchers etc.)?
Our current AutoQA server is running RHEL5. The AutoQA code that runs
on the server (autoqa script, watchers and some libs) needs to be
python-2.4 compliant. However, building and maintaining packages for
RHEL5 isn't the same process used for other releases. For that, and
other reasons, I'm anxious to move that system to RHEL6 in the near
future.
https://fedorahosted.org/autoqa/ticket/282
As soon as our production instance is moved to the new VLAN, I will
pursue reinstalling the system to RHEL6 (python-2.6). I don't have any
ETA's at this time other than "soon".
We already have several finally blocks in our tests in stable and a
couple in the libs, so breaking 2.4 compatibility wouldn't be a huge
deal in the tests since we haven't seen too many problems so far.
Yeah, it's certainly not a problem for the tests to use finally blocks.
All that code runs on the test clients. But the distinction between
client and server code isn't clear when it comes to the libs.
Hopefully ... this won't hold us back for much longer.
Thanks,
James
10:25 a.m.
On 04/07/2011 09:02 AM, James Laska wrote:
On Thu, 2011-04-07 at 08:50 -0600, Tim Flink wrote:
> This came up in the review of #293 and I thought that I would bring it
> up on the list.
>
> Since our AutoQA server runs RHEL5, it is also running python 2.4 which
> doesn't support "finally" blocks.
>
> What is the minimum version of python we want to support? Should all of
> our code be 2.4 compatible or just the stuff that will likely run on the
> autotest server ( events, watchers etc.)?
Our current AutoQA server is running RHEL5. The AutoQA code that runs
on the server (autoqa script, watchers and some libs) needs to be
python-2.4 compliant. However, building and maintaining packages for
RHEL5 isn't the same process used for other releases. For that, and
other reasons, I'm anxious to move that system to RHEL6 in the near
future.
https://fedorahosted.org/autoqa/ticket/282
As soon as our production instance is moved to the new VLAN, I will
pursue reinstalling the system to RHEL6 (python-2.6). I don't have any
ETA's at this time other than "soon".
+100 for the upgrade to RHEL6 when we can :)
> We already have several finally blocks in our tests in stable and
a
> couple in the libs, so breaking 2.4 compatibility wouldn't be a huge
> deal in the tests since we haven't seen too many problems so far.
Yeah, it's certainly not a problem for the tests to use finally blocks.
All that code runs on the test clients. But the distinction between
client and server code isn't clear when it comes to the libs.
Yeah, I'm mostly wondering how much we care about everything being 2.4
compatible. I'm reading your email as +1 for "only where it needs to be".
If I don't hear anything else soon, I'm just going to change the patch
for #293 to use a finally block since that is part of depcheck and not
executed on the AutoQA server, only on the test hosts.
Tim
1:43 p.m.
On Thu, 2011-04-07 at 09:25 -0600, Tim Flink wrote:
On 04/07/2011 09:02 AM, James Laska wrote:
> On Thu, 2011-04-07 at 08:50 -0600, Tim Flink wrote:
>> This came up in the review of #293 and I thought that I would bring it
>> up on the list.
>>
>> Since our AutoQA server runs RHEL5, it is also running python 2.4 which
>> doesn't support "finally" blocks.
>>
>> What is the minimum version of python we want to support? Should all of
>> our code be 2.4 compatible or just the stuff that will likely run on the
>> autotest server ( events, watchers etc.)?
>
> Our current AutoQA server is running RHEL5. The AutoQA code that runs
> on the server (autoqa script, watchers and some libs) needs to be
> python-2.4 compliant. However, building and maintaining packages for
> RHEL5 isn't the same process used for other releases. For that, and
> other reasons, I'm anxious to move that system to RHEL6 in the near
> future.
>
> https://fedorahosted.org/autoqa/ticket/282
>
> As soon as our production instance is moved to the new VLAN, I will
> pursue reinstalling the system to RHEL6 (python-2.6). I don't have any
> ETA's at this time other than "soon".
+100 for the upgrade to RHEL6 when we can :)
>> We already have several finally blocks in our tests in stable and a
>> couple in the libs, so breaking 2.4 compatibility wouldn't be a huge
>> deal in the tests since we haven't seen too many problems so far.
>
> Yeah, it's certainly not a problem for the tests to use finally blocks.
> All that code runs on the test clients. But the distinction between
> client and server code isn't clear when it comes to the libs.
Yeah, I'm mostly wondering how much we care about everything being 2.4
compatible. I'm reading your email as +1 for "only where it needs to be".
Yeah ... I'd like to be more specific, but I can't think of a easy way
to draw (a straight) line between stuff that can be 2.6 (or newer), and
2.4. The best I can think of is the 'autoqa' script and the watchers
need to be 2.4 compliant. Everything else can be 2.6 or newer. I know
that doesn't really define where the libs fit into this ... since some
of the watchers rely on autoqa libs.
If I don't hear anything else soon, I'm just going to change
the patch
for #293 to use a finally block since that is part of depcheck and not
executed on the AutoQA server, only on the test hosts.
You can put my Approved-By: on that commit! :)
Thanks,
James
7:11 a.m.
----- Original Message -----
Since our AutoQA server runs RHEL5, it is also running python 2.4
which
doesn't support "finally" blocks.
It does. Python 2.4 supports try..except and try..finally, but it does not support
try..except..finally. The last one is supported only from Python 2.5 up.
http://docs.python.org/reference/compound_stmts.html#try
6:08 p.m.
On 04/07/2011 08:50 AM, Tim Flink wrote:
This came up in the review of #293 and I thought that I would bring
it
up on the list.
Since our AutoQA server runs RHEL5, it is also running python 2.4 which
doesn't support "finally" blocks.
What is the minimum version of python we want to support? Should all of
our code be 2.4 compatible or just the stuff that will likely run on the
autotest server ( events, watchers etc.)?
We already have several finally blocks in our tests in stable and a
couple in the libs, so breaking 2.4 compatibility wouldn't be a huge
deal in the tests since we haven't seen too many problems so far.
I ran into another python 2.4 issue in master today (try/catch/finally
at util.py:276) and while I did fix my dev machine, I'm not sure
if we want to be changing this on master.
Since we're planning to move to RHEL6 soon, is it worth fixing this in
master or should we just make sure that stable is 2.4 compatible and
hold off on any incompatible changes until we upgrade production?
I'm tempted to say leave it alone for now and hopefully we'll upgrade
production to RHEL6 before we need to deal with this. I'll just patch my
RHEL5 machine for now and keep track of the required changes if we
should need them.
Thoughts?
Tim
2:08 a.m.
I ran into another python 2.4 issue in master today
(try/catch/finally
at util.py:276) and while I did fix my dev machine, I'm not sure
if we want to be changing this on master.
It's the method "valid_rpm(rpm_file)", I wrote it. But the method should be
called from the tests only, therefore just on the clients, shouldn't it? I thought it
should not affect the server side.
Since we're planning to move to RHEL6 soon, is it worth fixing this in
master or should we just make sure that stable is 2.4 compatible and
hold off on any incompatible changes until we upgrade production?
I'm tempted to say leave it alone for now and hopefully we'll upgrade
production to RHEL6 before we need to deal with this. I'll just patch
my
RHEL5 machine for now and keep track of the required changes if we
should need them.
We're thinking alike. Let's leave it as it is and patch it only when we know that
we certainly won't have RHEL6 for our next release. The change is trivial anyway.
4:43 a.m.
It's the method "valid_rpm(rpm_file)", I wrote it. But
the method
should be called from the tests only, therefore just on the clients,
shouldn't it? I thought it should not affect the server side.
I did a search for "finally" across all the AutoQA code. There are just
two other uses of try/catch/finally outside the tests, in ExceptionCatcher
class and send_mail function, which both seem to be called from the tests
only. So it seems to me like we're okay with having 2.4 on the server for now,
unless there are more kinds of constructs that would be unsupported with 2.4
9:01 a.m.
On 05/20/2011 01:08 AM, Kamil Paral wrote:
> I ran into another python 2.4 issue in master today
> (try/catch/finally at util.py:276) and while I did fix my dev
> machine, I'm not sure if we want to be changing this on master.
It's the method "valid_rpm(rpm_file)", I wrote it. But the method
should be called from the tests only, therefore just on the clients,
shouldn't it? I thought it should not affect the server side.
True, its only called on the clients but it is parsed at import time and
causes exceptions to be thrown at that time.
On a side note, 'make install' doesn't work on RHEL5 either - it tries
to byte-compile all of the python code for 2.4 and dies when it hits the
finally blocks. For some reason, building the RPM isn't affected, though.
> Since we're planning to move to RHEL6 soon, is it worth
fixing this
> in master or should we just make sure that stable is 2.4 compatible
> and hold off on any incompatible changes until we upgrade
> production?
>
> I'm tempted to say leave it alone for now and hopefully we'll
> upgrade production to RHEL6 before we need to deal with this. I'll
> just patch my RHEL5 machine for now and keep track of the required
> changes if we should need them.
We're thinking alike. Let's leave it as it is and patch it only when
we know that we certainly won't have RHEL6 for our next release. The
change is trivial anyway.
+10000 for moving to RHEL6. Dealing with AutoQA on RHEL5 for a dev
environment is painful.
Tim
4732
days inactive
4778
days old
autoqa-devel@lists.fedorahosted.org
9 comments
5 participants
participants (5)
-
James Laska -
Kamil Paral -
Luke Macken -
Tim Flink -
Vitezslav Humpa