Open Stack

> 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.

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.

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?

--Dan