Re: RHEL5 in AutoQA and python 2.4 compatibility

[Tim Flink]

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