[Openstack-operators] Nova cells v2 and operational impacts

Mike Dorman mdorman at godaddy.com
Tue Jul 21 23:21:18 UTC 2015


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


More information about the OpenStack-operators mailing list