Open Stack

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