[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