On 10/20/2014 08: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. >
Thanks for the write-up Andrew! Some thoughts/questions below. Looking forward to the discussion on some of these topics, and would be happy to review the code once we get to that point. > > 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. > Are we thinking of making this official by removing code that actually allows cells to be an actual tree of depth N? I am not sure if doing so would be a win, although it does complicate the RPC/Messaging/State code a bit, but if it's not being used, even though a nice generalization, why keep it around? > > 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. > Have there been any previous discussions on this topic? If so I'd really like to read up on those to make sure I understand the pros and cons before the summit session. > 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. > Some of that work has been done already, although in a somewhat ad-hoc fashion, were you thinking of extending objects to support this natively (whatever that means), or do we continue to inline the code in the existing object methods. > 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