Open Stack

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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev