<div dir="ltr"><div><div>Hi Andrew, <br><br></div>Since you have mentioned one approach to solve the flavor meta data to driver.spawn. I want to draw your attention to this code review thread as well, <a href="https://review.openstack.org/#/c/108238/">https://review.openstack.org/#/c/108238/</a>.<br><br></div>I didn't want to edit your etherpad notes, hence this email.<br><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">Regards,<br><br>Vineet Menon<br><br></div></div>
<br><div class="gmail_quote">On 30 October 2014 22:08, Andrew Laski <span dir="ltr"><<a href="mailto:andrew.laski@rackspace.com" target="_blank">andrew.laski@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have written up some points on an etherpad to use during the summit session <a href="https://etherpad.openstack.org/p/kilo-nova-cells" target="_blank">https://etherpad.openstack.<u></u>org/p/kilo-nova-cells</a> . Please read this over if possible before the session. There is an alternate approach to this work proposed and I expect we'll spend some time discussing it.<br>
<br>
If anyone would like to discuss it before then please reply here.<div><div class="h5"><br>
<br>
<br>
On 10/20/2014 02:00 PM, Andrew Laski wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
One of the big goals for the Kilo cycle by users and developers of the cells functionality within Nova is to get it to a point where it can be considered a first class citizen of Nova. Ultimately I think this comes down to getting it tested by default in Nova jobs, and making it easy for developers to work with. But there's a lot of work to get there. In order to raise awareness of this effort, and get the conversation started on a few things, I've summarized a little bit about cells and 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 it works for cells.<br>
<br>
Ultimately the goal is to improve maintainability of a large feature within the Nova code base.<br>
<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 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>
Plan:<br>
<br>
Fix flavor breakage in child cell which causes boot tests to fail. Currently the libvirt driver needs flavor.extra_specs which is not synced to the child cell. Some options are to sync flavor and extra specs to child cell db, or pass full data with the request. <a href="https://review.openstack.org/#/c/126620/1" target="_blank">https://review.openstack.org/#<u></u>/c/126620/1</a> offers a means of passing full data with the request.<br>
<br>
Determine proper switches to turn off Tempest tests for features that don't work with the goal of getting a voting job. Once this is in place we can move towards feature parity and work on internal refactorings.<br>
<br>
Work towards adding parity for host aggregates, security groups, and server groups. They should be made to work in a single cell setup, but the solution should not preclude them from being used in multiple cells. There needs to be some discussion as to whether a host aggregate or server group is a global concept or per cell concept.<br>
<br>
Work towards merging compute/api.py and compute/cells_api.py so that developers only need to make changes/additions in once place. The goal is for as much as possible to be hidden by the RPC layer, which will determine whether a call goes to a compute/conductor/cell.<br>
<br>
For syncing data between cells, look at using objects to handle the logic of writing data to the cell/parent and then syncing the data to the other.<br>
<br>
A potential migration scenario is to consider a non cells setup to be a child cell and converting to cells will mean setting up a parent cell and linking them. There are periodic tasks in place to sync data up from a child already, but a manual kick off mechanism will need to be added.<br>
<br>
<br>
Future plans:<br>
<br>
Something that has been considered, but is out of scope for now, is that the parent/api cell doesn't need the same data model as the child cell. Since the majority of what it does is act as a cache for API requests, it does not need all the data that a cell needs and what data it does need could be stored in a form that's optimized for reads.<br>
<br>
<br>
Thoughts?<br>
<br></div></div><span class="">
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</span></blockquote><div class="HOEnZb"><div class="h5">
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div>