Hi Andrew, 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, https://review.openstack.org/#/c/108238/.
I didn't want to edit your etherpad notes, hence this email. Regards, Vineet Menon On 30 October 2014 22:08, Andrew Laski <[email protected]> wrote: > I have written up some points on an etherpad to use during the summit > session https://etherpad.openstack.org/p/kilo-nova-cells . 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. > > If anyone would like to discuss it before then please reply here. > > > > On 10/20/2014 02:00 PM, Andrew Laski wrote: > >> 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. >> >> >> Goals: >> >> Testing of a single cell setup in the gate. >> Feature parity. >> Make cells the default implementation. Developers write code once and it >> works for cells. >> >> Ultimately the goal is to improve maintainability of a large feature >> within the Nova code base. >> >> >> Feature gaps: >> >> Host aggregates >> Security groups >> Server groups >> >> >> Shortcomings: >> >> Flavor syncing >> This needs to be addressed now. >> >> Cells scheduling/rescheduling >> Instances can not currently move between cells >> These two won't affect the default one cell setup so they will be >> addressed later. >> >> >> What does cells do: >> >> Schedule an instance to a cell based on flavor slots available. >> Proxy API requests to the proper cell. >> Keep a copy of instance data at the global level for quick retrieval. >> Sync data up from a child cell to keep the global level up to date. >> >> >> Simplifying assumptions: >> >> Cells will be treated as a two level tree structure. >> >> >> Plan: >> >> 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. >> https://review.openstack.org/#/c/126620/1 offers a means of passing full >> data with the request. >> >> 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. >> >> 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. >> >> 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. >> >> 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. >> >> 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. >> >> >> Future plans: >> >> 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. >> >> >> Thoughts? >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
