Hi, to help the discussion, a small compilation about the bugs and previous attempts to fix the missing functionality in cells.
Aggregates https://bugs.launchpad.net/nova/+bug/1161208 https://blueprints.launchpad.net/nova/+spec/cells-aggregate-support https://review.openstack.org/#/c/25813/ Server Groups https://bugs.launchpad.net/nova/+bug/1369518 Security Groups https://bugs.launchpad.net/nova/+bug/1274325 Belmiro On Tue, Oct 21, 2014 at 10:31 AM, Nikola Đipanov <ndipa...@redhat.com> wrote: > 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 > > OpenStackfirstname.lastname@example.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStackemail@example.com > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev