Open Stack

Michael,

Just to clear an assumption on my head: by new mysql database you mean a
new mysql instance?

If is the latter one, how do you see the deployment to be with 2 mysql
instances (possible in different clusters)?

Cheers,
Dani

On Wed, Jul 22, 2015 at 12:21 AM, Mike Dorman <mdorman at godaddy.com> wrote:

> Seems reasonable.
>
> For us already running v1, will we be creating another new cell database
> for v2?  Or will our existing v1 cell database become that second database
> under v2?
>
> Somewhat beyond the scope of this thread, but my main concern is the
> acrobatics going from v1 in Kilo to the hybrid v1/v2 in Liberty, to full
> v2 in Mitaka.  I think we all realize there will be some amount of pain to
> get to v2, but as long as that case for us existing cells users can be
> handled in a somewhat sane way, I’m happy.
>
> Mike
>
>
>
>
>
> On 7/21/15, 8:45 AM, "Michael Still" <mikal at stillhq.com> wrote:
>
> >Heya,
> >
> >the nova developer mid-cycle meetup is happening this week. We've been
> >talking through the operational impacts of cells v2, and thought it
> >would be a good idea to mention them here and get your thoughts.
> >
> >First off, what is cells v2? The plan is that _every_ nova deployment
> >will be running a new version of cells. The default will be a
> >deployment of a single cell, which will have the impact that existing
> >single cell deployments will end up having another mysql database that
> >is required by cells. However, you wont be required to bring up any
> >additional nova services at this point [1], as cells v2 lives inside
> >the nova-api service.
> >
> >The advantage of this approach is that cells stops being a weird
> >special case run by big deployments. We're forced to implement
> >everything in cells, instead of the bits that a couple of bigger
> >players cared enough about, and we're also forced to test it better.
> >It also means that smaller deployments can grow into big deployments
> >much more easily. Finally, it also simplifies the nova code, which
> >will reduce our tech debt.
> >
> >This is a large block of work, so cells v2 wont be fully complete in
> >Liberty. Cells v1 deployments will effective run both cells v2 and
> >cells v1 for this release, with the cells v2 code thinking that there
> >is a single very large cell. We'll continue the transition for cells
> >v1 deployments to pure cells v2 in the M release.
> >
> >So what's the actual question? We're introducing an additional mysql
> >database that every nova deployment will need to possess in Liberty.
> >We talked through having this data be in the existing database, but
> >that wasn't a plan that made us comfortable for various reasons. This
> >means that operators would need to do two db_syncs instead of one
> >during upgrades. We worry that this will be annoying to single cell
> >deployments.
> >
> >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.
> >
> >Cheers,
> >Michael
> >
> >1: there is some talk about having a separate pool of conductors to
> >handle the cells database, but this wont be implemented in Liberty.
> >
> >--
> >Rackspace Australia
> >
> >_______________________________________________
> >OpenStack-operators mailing list
> >OpenStack-operators at lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150722/a8af718c/attachment.html>