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 > _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators