[openstack-dev] [python3] tempest and grenade conversion to python 3.6

Matt Riedemann mriedemos at gmail.com
Wed Sep 19 02:57:23 UTC 2018


On 9/18/2018 9:52 PM, Matt Riedemann wrote:
> On 9/18/2018 12:28 PM, Doug Hellmann wrote:
>> What's probably missing is a version of the grenade job that allows us
>> to control that USE_PYTHON3 variable before and after the upgrade.
>>
>> I see a few different grenade jobs (neutron-grenade,
>> neutron-grenade-multinode,
>> legacy-grenade-dsvm-neutron-multinode-live-migration, possibly others).
>> Which ones are "current" and would make a good candidate as a base for a
>> new job?
> 
> Grenade just runs devstack on the old side (e.g. stable/rocky) using the 
> devstack stackrc file (which could have USE_PYTHON3 in it), runs tempest 
> 'smoke' tests to create some resources, saves off some information about 
> those resources in a "database" (just an ini file), then runs devstack 
> on the new side (e.g. master) using the new side stackrc file and 
> verifies those saved off resources made it through the upgrade. It's all 
> bash so there isn't anything python-specific about grenade.
> 
> I saw, but didn't comment on, the other thread about if it would be 
> possible to create a grenade-2to3 job. I'd think that is pretty doable 
> based on the USE_PYTHON3 variable. We'd just have that False on the old 
> side, and True on the new side, and devstack will do it's thing. Right 
> now the USE_PYTHON3 variable is global in devstack-gate [1] (which is 
> the thing that orchestrates the grenade run for the legacy jobs), but 
> I'm sure we could hack that to be specific to the base (old) and target 
> (new) release for the grenade run.
> 
> [1] 
> https://github.com/openstack-infra/devstack-gate/blob/95fa4343104eafa655375cce3546d27139211d13/devstack-vm-gate-wrap.sh#L434 
> 
> 

To answer Doug's original question, neutron-grenade-multinode is 
probably best to model for a new job if you want to test rolling 
upgrades, because that job has two compute nodes and leaves one on the 
'old' side so it would upgrade the controller services and one compute 
to Stein and leave the other compute at Rocky. So if you start with 
python2 on the old side and upgrade to python3 for everything except one 
compute, you'll have a pretty good idea of whether or not that rolling 
upgrade works through our various services and libraries, like the 
oslo.messaging stuff noted in the other thread.

-- 

Thanks,

Matt



More information about the OpenStack-dev mailing list