> 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 _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators