________________________________________
From: Matt Van Winkle
Sent: Wednesday, July 22, 2015 9:28 AM
To: Mike Dorman; Michael Still; openstack-operators@lists.openstack.org
Cc: Andrew Laski
Subject: Re: [Openstack-operators] Nova cells v2 and operational impacts
I think I primarily echo Mike's questions. For me, I'd like to see the
"primary" DB in cells v2 only have the data necessary for the APIs to know
which cell an instance is associate with - versus having to copy every
detail from every cell DB. I do wonder, for those of us using cells v1,
what that would mean in the interim versions (hopefully just L) and what
the migration path would look like. As Mike said, as long as these are
"sane", then my only other concern is hopefully removing the duplicated
data.
There will be a little more data than just instance->cell associations
but none of the data will be duplicated like in cells v1. For example,
we'll be storing flavor data in the new api database because that's
global and not particular to a cell and flavors will no longer be stored
or used from within the cell database.
As mentioned in another email it's a bit early to talk about the full
migration path because we're not yet looking at multiple cell support in
v2 so there's no way to migrate from v1. But in this interim period the
hybrid v1/v2 deployment is going to have the global cell be a v2 cell
with each current cell remaining untouched.
Thanks!
Matt
On 7/21/15 6:21 PM, "Mike Dorman" <mdor...@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" <mi...@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
----- End forwarded message -----
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
