On Wed, Sep 5, 2018 at 10:57 AM Matt Riedemann <mriede...@gmail.com> wrote: > > On 9/5/2018 8:47 AM, Mohammed Naser wrote: > > Could placement not do what happened for a while when the nova_api > > database was created? > > Can you be more specific? I'm having a brain fart here and not > remembering what you are referring to with respect to the nova_api DB.
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? > > > > I say this because I know that moving the database is a huge task for > > us, considering how big it can be in certain cases for us, and it > > means control plane outage too > > I'm pretty sure you were in the room in YVR when we talked about how > operators were going to do the database migration and were mostly OK > with what was discussed, which was a lot will just copy and take the > downtime (I think CERN said around 10 minutes for them, but they aren't > a public cloud either), but others might do something more sophisticated > and nova shouldn't try to pick the best fit for all. If we're provided the list of tables used by placement, we could considerably make the downtime smaller because we don't have to pull in the other huge tables like instances/build requests/etc What happens if things like server deletes happen while the placement service is down? > I'm definitely interested in what you do plan to do for the database > migration to minimize downtime. 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? Just throwing ideas here. > +openstack-operators ML since this is an operators discussion now. > > -- > > Thanks, > > Matt -- 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
