[Openstack-operators] [openstack-dev] [nova] [placement] extraction (technical) update
dms at danplanet.com
Wed Sep 5 16:41:31 UTC 2018
> I think there was a period in time where the nova_api database was created
> where entires would try to get pulled out from the original nova database and
> then checking nova_api if it doesn't exist afterwards (or vice versa). One
> of the cases that this was done to deal with was for things like instance types
> or flavours.
> I don't know the exact details but I know that older instance types exist in
> the nova db and the newer ones are sitting in nova_api. Something along
> those lines?
Yep, we've moved entire databases before in nova with minimal disruption
to the users. Not just flavors, but several pieces of data came out of
the "main" database and into the api database transparently. It's
doable, but with placement being split to a separate
project/repo/whatever, there's not really any option for being graceful
about it in this case.
> At this point, I'm thinking turn off placement, setup the new one, do
> the migration
> of the placement-specific tables (this can be a straightforward documented task
> OR it would be awesome if it was a placement command (something along
> the lines of `placement-manage db import_from_nova`) which would import all
> the right things
> The idea of having a command would be *extremely* useful for deployment tools
> in automating the process and it also allows the placement team to selectively
> decide what they want to onboard?
Well, it's pretty cut-and-dried as all the tables in nova-api are either
for nova or placement, so there's not much confusion about what belongs.
I'm not sure that doing this import in python is really the most
efficient way. I agree a placement-manage command would be ideal from an
"easy button" point of view, but I think a couple lines of bash that
call mysqldump are likely to vastly outperform us doing it natively in
python. We could script exec()s of those commands from python, but.. I
think I'd rather just see that as a shell script that people can easily
alter/test on their own.
Just curious, but in your case would the service catalog entry change at
all? If you stand up the new placement in the exact same spot, it
shouldn't, but I imagine some people will have the catalog entry change
slightly (even if just because of a VIP or port change). Am I
remembering correctly that the catalog can get cached in various places
such that much of nova would need a restart to notice?
More information about the OpenStack-operators