On 10/22/2014 12:52 AM, Michael Still wrote:
Thanks for this.

It would be interesting to see how much of this work you think is
achievable in Kilo. How long do you see this process taking? In line
with that, is it just you currently working on this? Would calling for
volunteers to help be meaningful?

I think that getting a single cell setup tested in the gate is achievable. I think feature parity might be a stretch but could be achievable with enough hands to work on it. Honestly I think that making cells the default implementation is going to take more than a cycle. But I think we can get some specifics worked out as to the direction and may be able to get to a point where the remaining work is mostly mechanical.

At the moment it is mainly me working on this with some support from a couple of people. Volunteers would certainly be welcomed on this effort though. If it would be useful perhaps we could even have a cells subgroup to track progress and direction of this effort.


Michael

On Tue, Oct 21, 2014 at 5:00 AM, Andrew Laski
<andrew.la...@rackspace.com> 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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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

Reply via email to