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 <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
