Open Stack

Excerpts from Matt Riedemann's message of 2018-09-06 15:58:41 -0500:
> 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).

Making placement read from both files should be pretty straightforward,
right? It's possible to pass default_config_files and default_config_dirs
to oslo.config, and the functions that build the original defaults
are part of the public API (find_config_files and find_config_dirs
in oslo_config.cfg) so the placement service can call them twice
(with different "project" arguments) and merge the results before
initializing the ConfigOpts instance.

Doug

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