Open Stack

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.

Thanks!
Matt

On 7/21/15 6:21 PM, "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