Open Stack

On Wed, Jul 22, 2015 at 1:14 AM, gustavo panizzo (gfa) <gfa at zumbi.com.ar> wrote:
>
>
> 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

So, first off the schema numbers will be separate for each database,
so if the numbers are ever the same in both that will be entirely by
accident.

That said, I see that you're saying about schema upgrades.
Unfortunately nova-api needs to talk to both databases, so the
databases need to be upgraded at the same time. However, I think that
our expand and contract support might help you here, in that you
should be able to alter the database schema before upgrading the
binaries. That would should you time to resolve migration issues.

Hope this helps,
Michael

-- 
Rackspace Australia