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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
