Open Stack

I wanted to recap some upgrade-specific stuff from today outside of the 
other [1] technical extraction thread.

Chris has a change up for review [2] which prompted the discussion.

That change makes placement only work with placement.conf, not 
nova.conf, but does get a passing tempest run in the devstack patch [3].

The main issue here is upgrades. If you think of this like deprecating 
config options, the old config options continue to work for a release 
and then are dropped after a full release (or 3 months across boundaries 
for CDers) [4]. Given that, Chris's patch would break the standard 
deprecation policy. Clearly one simple way outside of code to make that 
work is just copy and rename nova.conf to placement.conf and voila. But 
that depends on *all* deployment/config tooling to get that right out of 
the gate.

The other obvious thing is the database. The placement repo code as-is 
today still has the check for whether or not it should use the placement 
database but falls back to using the nova_api database [5]. So 
technically you could point the extracted placement at the same nova_api 
database and it should work. However, at some point deployers will 
clearly need to copy the placement-related tables out of the nova_api DB 
to a new placement DB and make sure the 'migrate_version' table is 
dropped so that placement DB schema versions can reset to 1.

With respect to grenade and making this work in our own upgrade CI 
testing, we have I think two options (which might not be mutually 
exclusive):

1. Make placement support using nova.conf if placement.conf isn't found 
for Stein with lots of big warnings that it's going away in T. Then 
Rocky nova.conf with the nova_api database configuration just continues 
to work for placement in Stein. I don't think we then have any grenade 
changes to make, at least in Stein for upgrading *from* Rocky. Assuming 
fresh devstack installs in Stein use placement.conf and a 
placement-specific database, then upgrades from Stein to T should also 
be OK with respect to grenade, but likely punts the cut-over issue for 
all other deployment projects (because we don't CI with grenade doing 
Rocky->Stein->T, or FFU in other words).

2. If placement doesn't support nova.conf in Stein, then grenade will 
require an (exceptional) [6] from-rocky upgrade script which will (a) 
write out placement.conf fresh and (b) run a DB migration script, likely 
housed in the placement repo, to create the placement database and copy 
the placement-specific tables out of the nova_api database. Any script 
like this is likely needed regardless of what we do in grenade because 
deployers will need to eventually do this once placement would drop 
support for using nova.conf (if we went with option 1).

That's my attempt at a summary. It's going to be very important that 
operators and deployment project contributors weigh in here if they have 
strong preferences either way, and note that we can likely do both 
options above - grenade could do the fresh cutover from rocky to stein 
but we allow running with nova.conf and nova_api DB in placement in 
stein with plans to drop that support in T.

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/subject.html#134184
[2] https://review.openstack.org/#/c/600157/
[3] https://review.openstack.org/#/c/600162/
[4] 
https://governance.openstack.org/tc/reference/tags/assert_follows-standard-deprecation.html#requirements
[5] 
https://github.com/openstack/placement/blob/fb7c1909/placement/db_api.py#L27
[6] https://docs.openstack.org/grenade/latest/readme.html#theory-of-upgrade

-- 

Thanks,

Matt