Michael, Just to clear an assumption on my head: by new mysql database you mean a new mysql instance?
If is the latter one, how do you see the deployment to be with 2 mysql instances (possible in different clusters)? Cheers, Dani On Wed, Jul 22, 2015 at 12:21 AM, 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 >
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators