> -----Original Message----- > From: Andrew Laski [mailto:[email protected]] > 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 > > <[email protected]> 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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
