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@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 <mi...@stillhq.com<mailto: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<mailto: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
