Open Stack

Hi,

Many thanks to Steve to link these topics together.

+1

Consider that there are lots of production installation of cells solution, the improvement on cells are definitely necessary. 

And also hope to add the following demand for the large cloud operator ( especially cloud for NFV ) in the agenda:

1) large cloud operator ask multi-vendor to build the distributed but unified cloud together. (each vendor has his own OpenStack based solution)
2) restful API /CLI is required for each site to make the cloud always workable and manageable.
3) the unified cloud need to expose open and standard api

That's drive force for OpenStack cascading, let's try to work together to see if cells can evolve to solve this demands.

Best Regards
Chaoyi Huang ( Joe Huang )


-----Original Message-----
From: Steve Gordon [mailto:sgordon at redhat.com] 
Sent: Wednesday, October 22, 2014 10:10 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] Cells conversation starter

----- Original Message -----
> From: "Andrew Laski" <andrew.laski at rackspace.com>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev at lists.openstack.org>
> 
> 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.

In terms of future plans I'd like to also explore how continued iteration on the Cells concept might line up against the use cases presented in the recent threads on OpenStack cascading:

* http://lists.openstack.org/pipermail/openstack-dev/2014-September/047470.html
* http://lists.openstack.org/pipermail/openstack-dev/2014-October/047526.html

Thanks,

Steve

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev