<div dir="ltr"><div>Hi,</div><div>to help the discussion, </div><div>a small compilation about the bugs and previous attempts to fix the </div><div>missing functionality in cells.</div><div><br></div><div><br></div><div>Aggregates</div><div><a href="https://bugs.launchpad.net/nova/+bug/1161208">https://bugs.launchpad.net/nova/+bug/1161208</a></div><div><a href="https://blueprints.launchpad.net/nova/+spec/cells-aggregate-support">https://blueprints.launchpad.net/nova/+spec/cells-aggregate-support</a></div><div><a href="https://review.openstack.org/#/c/25813/">https://review.openstack.org/#/c/25813/</a></div><div><br></div><div>Server Groups</div><div><a href="https://bugs.launchpad.net/nova/+bug/1369518">https://bugs.launchpad.net/nova/+bug/1369518</a></div><div><br></div><div>Security Groups</div><div><a href="https://bugs.launchpad.net/nova/+bug/1274325">https://bugs.launchpad.net/nova/+bug/1274325</a></div><div><br></div><div><br></div><div>Belmiro</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 21, 2014 at 10:31 AM, Nikola Đipanov <span dir="ltr"><<a href="mailto:ndipanov@redhat.com" target="_blank">ndipanov@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/20/2014 08:00 PM, Andrew Laski wrote:<br>
> One of the big goals for the Kilo cycle by users and developers of the<br>
> cells functionality within Nova is to get it to a point where it can be<br>
> considered a first class citizen of Nova.  Ultimately I think this comes<br>
> down to getting it tested by default in Nova jobs, and making it easy<br>
> for developers to work with.  But there's a lot of work to get there.<br>
> In order to raise awareness of this effort, and get the conversation<br>
> started on a few things, I've summarized a little bit about cells and<br>
> this effort below.<br>
><br>
><br>
> Goals:<br>
><br>
> Testing of a single cell setup in the gate.<br>
> Feature parity.<br>
> Make cells the default implementation.  Developers write code once and<br>
> it works for  cells.<br>
><br>
> Ultimately the goal is to improve maintainability of a large feature<br>
> within the Nova code base.<br>
><br>
<br>
</span>Thanks for the write-up Andrew! Some thoughts/questions below. Looking<br>
forward to the discussion on some of these topics, and would be happy to<br>
review the code once we get to that point.<br>
<span class=""><br>
><br>
> Feature gaps:<br>
><br>
> Host aggregates<br>
> Security groups<br>
> Server groups<br>
><br>
><br>
> Shortcomings:<br>
><br>
> Flavor syncing<br>
>     This needs to be addressed now.<br>
><br>
> Cells scheduling/rescheduling<br>
> Instances can not currently move between cells<br>
>     These two won't affect the default one cell setup so they will be<br>
> addressed later.<br>
><br>
><br>
> What does cells do:<br>
><br>
> Schedule an instance to a cell based on flavor slots available.<br>
> Proxy API requests to the proper cell.<br>
> Keep a copy of instance data at the global level for quick retrieval.<br>
> Sync data up from a child cell to keep the global level up to date.<br>
><br>
><br>
> Simplifying assumptions:<br>
><br>
> Cells will be treated as a two level tree structure.<br>
><br>
<br>
</span>Are we thinking of making this official by removing code that actually<br>
allows cells to be an actual tree of depth N? I am not sure if doing so<br>
would be a win, although it does complicate the RPC/Messaging/State code<br>
a bit, but if it's not being used, even though a nice generalization,<br>
why keep it around?<br>
<span class=""><br>
><br>
> Plan:<br>
><br>
> Fix flavor breakage in child cell which causes boot tests to fail.<br>
> Currently the libvirt driver needs flavor.extra_specs which is not<br>
> synced to the child cell.  Some options are to sync flavor and extra<br>
> specs to child cell db, or pass full data with the request.<br>
> <a href="https://review.openstack.org/#/c/126620/1" target="_blank">https://review.openstack.org/#/c/126620/1</a> offers a means of passing full<br>
> data with the request.<br>
><br>
> Determine proper switches to turn off Tempest tests for features that<br>
> don't work with the goal of getting a voting job.  Once this is in place<br>
> we can move towards feature parity and work on internal refactorings.<br>
><br>
> Work towards adding parity for host aggregates, security groups, and<br>
> server groups.  They should be made to work in a single cell setup, but<br>
> the solution should not preclude them from being used in multiple<br>
> cells.  There needs to be some discussion as to whether a host aggregate<br>
> or server group is a global concept or per cell concept.<br>
><br>
<br>
</span>Have there been any previous discussions on this topic? If so I'd really<br>
like to read up on those to make sure I understand the pros and cons<br>
before the summit session.<br>
<span class=""><br>
> Work towards merging compute/api.py and compute/cells_api.py so that<br>
> developers only need to make changes/additions in once place.  The goal<br>
> is for as much as possible to be hidden by the RPC layer, which will<br>
> determine whether a call goes to a compute/conductor/cell.<br>
><br>
> For syncing data between cells, look at using objects to handle the<br>
> logic of writing data to the cell/parent and then syncing the data to<br>
> the other.<br>
><br>
<br>
</span>Some of that work has been done already, although in a somewhat ad-hoc<br>
fashion, were you thinking of extending objects to support this natively<br>
(whatever that means), or do we continue to inline the code in the<br>
existing object methods.<br>
<div class="HOEnZb"><div class="h5"><br>
> A potential migration scenario is to consider a non cells setup to be a<br>
> child cell and converting to cells will mean setting up a parent cell<br>
> and linking them.  There are periodic tasks in place to sync data up<br>
> from a child already, but a manual kick off mechanism will need to be<br>
> added.<br>
><br>
><br>
> Future plans:<br>
><br>
> Something that has been considered, but is out of scope for now, is that<br>
> the parent/api cell doesn't need the same data model as the child cell.<br>
> Since the majority of what it does is act as a cache for API requests,<br>
> it does not need all the data that a cell needs and what data it does<br>
> need could be stored in a form that's optimized for reads.<br>
><br>
><br>
> Thoughts?<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>