Open Stack

On Tue, Sep 18, 2018 at 09:52:50PM -0500, 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.

This isn't quite right, we run devstack on the old side. But, on the new side
we don't actually run devstack. Grenade updates the code, runs DB migrations
(and any other mandatory upgrade steps), and then just relaunches the service.
That's kind of the point to make sure new code works with old config.

The target (ie new side) stackrc and localrc/local.conf are there for the
common functions shared between devstack and grenade which are used to do things
like pull the code and start services to make sure they run against the proper
branches. Since there isn't any point in reimplementing the same exact thing.
But we don't do a full devstack run, that's why you see only see stack.sh run
once in the logs on a grenade job.

> 
> 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.

I don't think this will work because we won't be running any initial python 3
setup on the system. I think it will just update paths and try to use python3
pip and python3 paths for things, but it will be missing the things it needs
for those to work. It's probably worth a try either way (a quick experiment
to say definitively) but my gut is telling me that it's not going to be that
simple.


-Matt Treinish

> 
> [1] https://github.com/openstack-infra/devstack-gate/blob/95fa4343104eafa655375cce3546d27139211d13/devstack-vm-gate-wrap.sh#L434
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180919/3676e97e/attachment.sig>