On 8/28/2018 10:57 AM, Dan Smith wrote:
The from-rocky will also need to extract data from the nova-api database
for the placement tables and put it into the new placement database (as
real operators will have to do). It'll need to do this after the split
code has been installed and the schema has been sync'd. Without this,
the pre-upgrade resources won't have allocations known by the split
placement service. I do not think we should cheat by just pointing the
split placement at nova's database.
Yes excellent points.
Also, ISTR you added some allocation/inventory checking to devstack via
hook, maybe after the tempest job ran? We might want to add some stuff
to grenade to verify the pre/post resource allocations before we start
this move so we can make sure they're still good after we roll. I'll see
if I can hack something up to that effect.
It's in nova:
https://github.com/openstack/nova/blob/8b4fcdfdc6c59e024e7639e0d2da6ccbea5c73d3/gate/post_test_hook.sh#L55
And only run in the nova-next job:
https://github.com/openstack/nova/blob/8b4fcdfdc6c59e024e7639e0d2da6ccbea5c73d3/playbooks/legacy/nova-next/run.yaml#L62
Grenade already has it's own "resources db" right? So we can shove
things in there before we upgrade and then verify they are still there
after the upgrade? The post-tempest check I added to nova is looking for
orphaned allocations, meaning we successfully completed some operation,
like resize for example, but failed to cleanup after ourselves (which we
missed quite a bit of that in Pike).
--
Thanks,
Matt
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
