On Thu, Sep 6, 2018, 8:40 PM Rochelle Grober <rochelle.gro...@huawei.com> wrote:
> Sounds like an important discussion to have with the operators in Denver. > Should put this on the schedule for the Ops meetup. > > --Rocky > We are planning to attend the upgrade sessions on Monday as a group. How about we put it there? -Erik > > > -----Original Message----- > > From: Matt Riedemann [mailto:mriede...@gmail.com] > > Sent: Thursday, September 06, 2018 1:59 PM > > To: OpenStack Development Mailing List (not for usage questions) > > <openstack-...@lists.openstack.org>; openstack- > > operat...@lists.openstack.org > > Subject: [openstack-dev] [nova][placement][upgrade][qa] Some upgrade- > > specific news on extraction > > > > 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 > __________________________________________________________________________ > 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 >
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
