<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
Sounds like a good plan to me.<br>
<br>
Thanks,<br>
Kevin <strong>
<div><font face="Tahoma" color="#000000" size="2"> </font></div>
</strong>
<hr tabindex="-1">
<font face="Tahoma" size="2"><b>From:</b> David Medberry<br>
<b>Sent:</b> Tuesday, July 21, 2015 7:51:50 AM<br>
<b>To:</b> Michael Still<br>
<b>Cc:</b> openstack-operators@lists.openstack.org; Andrew Laski<br>
<b>Subject:</b> Re: [Openstack-operators] Nova cells v2 and operational impacts<br>
</font><br>
<div></div>
<div>
<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>
</div>
</body>
</html>