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
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
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
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
----- 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.
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
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.
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
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
autoqa-devel@lists.fedorahosted.org