[Openstack-operators] [openstack-dev] [nova][placement][upgrade][qa] Some upgrade-specific news on extraction
mnaser at vexxhost.com
Fri Sep 7 15:24:51 UTC 2018
On Fri, Sep 7, 2018 at 11:18 AM Dan Smith <dms at danplanet.com> wrote:
> > 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
> > . 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.
> I think it's wrong to act like placement and nova-api schemas are the
> same. One is a clone of the other at a point in time, and technically it
> will work today. However the placement db sync tool won't do the right
> thing, and I think we run the major risk of operators not fully grokking
> what is going on here, seeing that pointing placement at nova-api
> "works" and move on. Later, when we add the next placement db migration
> (which could technically happen in stein), they will either screw their
> nova-api schema, or mess up their versioning, or be unable to apply the
> placement change.
> > 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).
> As I have said above and in the review, I really think this is the wrong
> approach. At the current point of time, the placement schema is a clone
> of the nova-api schema, and technically they will work. At the first point
> that placement evolves its schema, that will no longer be a workable
> solution, unless we also evolve nova-api's database in lockstep.
> > 2. If placement doesn't support nova.conf in Stein, then grenade will
> > require an (exceptional)  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).
> Yep, and I'm asserting that we should write that script, make grenade do
> that step, and confirm that it works. I think operators should do that
> step during the stein upgrade because that's where the fork/split of
> history and schema is happening. I'll volunteer to do the grenade side
> at least.
> Maybe it would help to call out specifically that, IMHO, this can not
> and should not follow the typical config deprecation process. It's not a
> simple case of just making sure we "find" the nova-api database in the
> various configs. The problem is that _after_ the split, they are _not_
> the same thing and should not be considered as the same. Thus, I think
> to avoid major disaster and major time sink for operators later, we need
> to impose the minor effort now to make sure that they don't take the
> process of deploying a new service lightly.
I think that's a valid different approach. I'd be okay with this if
scripts and documentation is out there. In this case, Grenade stuff
will be really
useful asset to look over upgrades with.
> Jay's original relatively small concern was that deploying a new
> placement service and failing to properly configure it would result in a
> placement running with the default, empty, sqlite database. That's a
> valid concern, and I think all we need to do is make sure we fail in
> that case, explaining the situation.
If it's a hard fail, that seems reasonable and ensures no surprises occur
during the upgrade or much later.
> We just had a hangout on the topic and I think we've come around to the
> consensus that just removing the default-to-empty-sqlite behavior is the
> right thing to do. Placement won't magically find nova.conf if it exists
> and jump into its database, and it also won't do the silly thing of
> starting up with an empty database if the very important config step is
> missed in the process of deploying placement itself. Operators will have
> to deploy the new package and do the database surgery (which we will
> provide instructions and a script for) as part of that process, but
> there's really no other sane alternative without changing the current
> agreed-to plan regarding the split.
> Is everyone okay with the above summary of the outcome?
I've dropped my -1 from this given the discussion
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
Mohammed Naser — vexxhost
D. 800-910-1726 ext. 200
E. mnaser at vexxhost.com
More information about the OpenStack-operators