Open Stack

Sounds like a good plan to me.

Thanks,
Kevin

________________________________
From: David Medberry
Sent: Tuesday, July 21, 2015 7:51:50 AM
To: Michael Still
Cc: openstack-operators at lists.openstack.org; Andrew Laski
Subject: Re: [Openstack-operators] Nova cells v2 and operational impacts

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<mailto: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<mailto: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/13b0abc6/attachment.html>