[openstack-dev] [release][stable] OpenStack 2014.2.4 (juno)

Matt Riedemann mriedem at linux.vnet.ibm.com
Fri Nov 20 23:47:10 UTC 2015



On 11/20/2015 6:43 AM, Sean Dague wrote:
> On 11/19/2015 08:56 PM, Rochelle Grober wrote:
>> Again, my plea to leave the Juno repository on git.openstack.org, but locked down to enable at least grenade testing for Juno->Kilo upgrades.  For upgrade testing purposes, python2.6 is not needed as any cloud would have to upgrade python before upgrading to kilo.  The testing could/should be limited to only occurring when Kilo backports are proposed.  The nodepool requirements should be very small except for the pre-release periods remaining for Kilo, especially if the testing is restricted to grenade only.
>>
>> Thanks for the ear. I'm expecting to participate in the stable releases team, and to bring a developer along with me;-)
>
> This really isn't a good idea.
>
> Grenade makes sure the old side works first, with Tempest. Tempest won't
> support juno any more, you'd need to modify the job to do something else
> here.
>
> Often times there are breaks due to upstream changes that require fixes
> on the old side, which is now impossible.
>
> Juno being eol means we expect you are already off of it, not that you
> should be soon.
>
> 	-Sean
>

I'm assuming Tempest will create a tag when it drops support for Juno. 
So theoretically you could bring up Juno 2014.2.4, run Tempest at the 
juno-eol tag, then upgrade to stable/kilo, checkout trunk Tempest and 
run that against the (new) kilo side.

If there are breaks on the (old) juno side, like upstream dependency 
issues (which was usually our problem), then we can't cap them in the 
code since the stable/juno branch is gone. You could somehow hack that 
into grenade maybe, but that gets pretty gross and doesn't reflect 
reality for downstream consumers of the 2014.2.4 release. This, in my 
mind, is the biggest reason we wouldn't be doing this kind of upgrade 
testing on stable/kilo changes.

-- 

Thanks,

Matt Riedemann




More information about the OpenStack-dev mailing list