Open Stack

On 09/07/2018 11:17 AM, Dan Smith 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.
> 
> 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?

Yes from my perspective.

-jay