Open Stack

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
> > [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.
>
> 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) [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).
>
> 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
the appropriate
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

https://review.openstack.org/#/c/600157/

> --Dan
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Mohammed Naser — vexxhost
-----------------------------------------------------
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mnaser at vexxhost.com
W. http://vexxhost.com