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
