Open Stack

Also, if there is feedback, getting it in today or tomorrow would be most
effective.

Michael, this plan works for me/us. TWC. -d

On Tue, Jul 21, 2015 at 9: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150721/d265e27d/attachment.html>