Open Stack

Hi Andrew,

Since you have mentioned one approach to solve the flavor meta data to
driver.spawn. I want to draw your attention to this code review thread as
well, https://review.openstack.org/#/c/108238/.

I didn't want to edit your etherpad notes, hence this email.


Regards,

Vineet Menon


On 30 October 2014 22:08, Andrew Laski <andrew.laski at rackspace.com> wrote:

> I have written up some points on an etherpad to use during the summit
> session https://etherpad.openstack.org/p/kilo-nova-cells . Please read
> this over if possible before the session.  There is an alternate approach
> to this work proposed and I expect we'll spend some time discussing it.
>
> If anyone would like to discuss it before then please reply here.
>
>
>
> On 10/20/2014 02: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.
>>
>>
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141030/366e3f3a/attachment.html>