<div dir="ltr">Also, if there is feedback, getting it in today or tomorrow would be most effective. <div><br></div><div>Michael, this plan works for me/us. TWC. -d</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 21, 2015 at 9:45 AM, Michael Still <span dir="ltr"><<a href="mailto:mikal@stillhq.com" target="_blank">mikal@stillhq.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Heya,<br>
<br>
the nova developer mid-cycle meetup is happening this week. We've been<br>
talking through the operational impacts of cells v2, and thought it<br>
would be a good idea to mention them here and get your thoughts.<br>
<br>
First off, what is cells v2? The plan is that _every_ nova deployment<br>
will be running a new version of cells. The default will be a<br>
deployment of a single cell, which will have the impact that existing<br>
single cell deployments will end up having another mysql database that<br>
is required by cells. However, you wont be required to bring up any<br>
additional nova services at this point [1], as cells v2 lives inside<br>
the nova-api service.<br>
<br>
The advantage of this approach is that cells stops being a weird<br>
special case run by big deployments. We're forced to implement<br>
everything in cells, instead of the bits that a couple of bigger<br>
players cared enough about, and we're also forced to test it better.<br>
It also means that smaller deployments can grow into big deployments<br>
much more easily. Finally, it also simplifies the nova code, which<br>
will reduce our tech debt.<br>
<br>
This is a large block of work, so cells v2 wont be fully complete in<br>
Liberty. Cells v1 deployments will effective run both cells v2 and<br>
cells v1 for this release, with the cells v2 code thinking that there<br>
is a single very large cell. We'll continue the transition for cells<br>
v1 deployments to pure cells v2 in the M release.<br>
<br>
So what's the actual question? We're introducing an additional mysql<br>
database that every nova deployment will need to possess in Liberty.<br>
We talked through having this data be in the existing database, but<br>
that wasn't a plan that made us comfortable for various reasons. This<br>
means that operators would need to do two db_syncs instead of one<br>
during upgrades. We worry that this will be annoying to single cell<br>
deployments.<br>
<br>
We therefore propose the following:<br>
<br>
 - all operators when they hit Liberty will need to add a new<br>
connection string to their nova.conf which configures this new mysql<br>
database, there will be a release note to remind you to do this.<br>
 - we will add a flag which indicates if a db_sync should imply a sync<br>
of the cells database as well. The default for this flag will be true.<br>
<br>
This means that you can still do these syncs separately if you want,<br>
but we're not forcing you to remember to do it if you just want it to<br>
always happen at the same time.<br>
<br>
Does this sound acceptable? Or are we over thinking this? We'd<br>
appreciate your thoughts.<br>
<br>
Cheers,<br>
Michael<br>
<br>
1: there is some talk about having a separate pool of conductors to<br>
handle the cells database, but this wont be implemented in Liberty.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Rackspace Australia<br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</font></span></blockquote></div><br></div>