On Wed, Sep 5, 2018 at 12:41 PM Dan Smith <d...@danplanet.com> wrote: > > > 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?
We already have placement in the catalog and it's behind a load balancer so changing the backends resolves things right away, so we likely won't be needing any restarts (and I don't think OSA will either because it uses the same model). > --Dan -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mna...@vexxhost.com W. http://vexxhost.com __________________________________________________________________________ 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
