[Openstack-operators] Nova cells v2 and operational impacts
gustavo panizzo (gfa)
gfa at zumbi.com.ar
Tue Jul 21 15:14:06 UTC 2015
On 2015-07-21 22:45, Michael Still wrote:
> We therefore propose the following:
>
> - all operators when they hit Liberty will need to add a new
> connection string to their nova.conf which configures this new mysql
> database, there will be a release note to remind you to do this.
> - we will add a flag which indicates if a db_sync should imply a sync
> of the cells database as well. The default for this flag will be true.
>
> This means that you can still do these syncs separately if you want,
> but we're not forcing you to remember to do it if you just want it to
> always happen at the same time.
>
> Does this sound acceptable? Or are we over thinking this? We'd
> appreciate your thoughts.
as an op I would like to know if nova can work with the db at different
shema level
nova api = N
nova db = N
nova cell db = M
nova compute = M & N
I have no problem doing the db updates in certain order (example: nova
db before nova cell db) but I want to be able to keep running if the
second db upgrade fails and I need more time to fix it.
a grenade job in the gate testing that would be great
--
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333
keybase: http://keybase.io/gfa
More information about the OpenStack-operators
mailing list