Open Stack

> -----Original Message-----
> From: Andrew Laski [mailto:andrew.laski at rackspace.com]
> Sent: 22 October 2014 21:12
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Nova] Cells conversation starter
> 
> 
> 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.
> 

I think getting to feature parity would be a good Kilo objective. Moving to default is another step which would need migration
scripts from the non-cells setups which would need heavy testing. Aiming for L for that would seem reasonable given that we
are not drowning in volunteers.

> 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.
> 

CERN and BARC (Bhaba Atomic Research Centre in Mumbai) would be interested in helping to close the gap. 

Tim

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