<div dir="ltr"><div><div><div><div>Michael,<br><br></div>Just to clear an assumption on my head: by new mysql database you mean a new mysql instance?<br><br></div>If is the latter one, how do you see the deployment to be with 2 mysql instances (possible in different clusters)?<br><br></div>Cheers,<br></div>Dani<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 22, 2015 at 12:21 AM, Mike Dorman <span dir="ltr"><<a href="mailto:mdorman@godaddy.com" target="_blank">mdorman@godaddy.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Seems reasonable.<br>
<br>
For us already running v1, will we be creating another new cell database<br>
for v2?  Or will our existing v1 cell database become that second database<br>
under v2?<br>
<br>
Somewhat beyond the scope of this thread, but my main concern is the<br>
acrobatics going from v1 in Kilo to the hybrid v1/v2 in Liberty, to full<br>
v2 in Mitaka.  I think we all realize there will be some amount of pain to<br>
get to v2, but as long as that case for us existing cells users can be<br>
handled in a somewhat sane way, I’m happy.<br>
<span class="HOEnZb"><font color="#888888"><br>
Mike<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<br>
On 7/21/15, 8:45 AM, "Michael Still" <<a href="mailto:mikal@stillhq.com">mikal@stillhq.com</a>> wrote:<br>
<br>
>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>
><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>
_______________________________________________<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>
</div></div></blockquote></div><br></div>