[Openstack] Nova Cells

Day, Phil philip.day at hp.com
Fri Jul 13 16:01:47 UTC 2012


Hi Chris,

What happens to notifications to other compute servers that are generated as side effect of VM creation a result of using the IPtables firewall driver ?    Are they somehow propagated to other Cells, or is there something that keeps all VMs in a particular security group within a Cell ?

I looked in the doc and code, but I couldn't see anything that seems to indicate either way.

Thanks
Phil


From: openstack-bounces+philip.day=hp.com at lists.launchpad.net [mailto:openstack-bounces+philip.day=hp.com at lists.launchpad.net] On Behalf Of Chris Behrens
Sent: 12 July 2012 20:13
To: Michael J Fork
Cc: openstack at lists.launchpad.net; Chris Behrens
Subject: Re: [Openstack] Nova Cells

Partially developed.  This probably isn't much use, but I'll throw it out there: http://comstud.com/cells.pdf

ATM the messy code speaks for itself here:

https://github.com/comstud/nova/tree/cells_service

The basic architecture is:

Top level cell with API service has DB, rabbit, and the nova-cells service.  API's compute_api_class is overridden to use a new class that shoves every action on an instance into the nova-cells service, telling it which cell to route the request to based on instance['cell_name'].  The nova-cells service routes the request to correct cell as requested... 1 hop at a time to the nova-cells service in each child.

(Each child runs this new nova-cells service also)

If nova-cells service gets a message destined for itself, it'll call the appropriate compute_api call in the child.

DB updates are hooked in the child and pushed up to parent cells.

New instance creation is slightly different.  API will create the DB entry up front... and pass the uuid and all of the same data to the nova-cells service, which will pick a cell for the instance.  When it is decided to use the 'current cell' in some child, it will create the DB entry there as well... push a notification upward... and cast the message over to the host scheduler (current scheduler).  And the build continues as normal from there (host is picked, and message is casted to the host, etc).

There's some code to sync instances in case of lost DB updates.. but there's improvements to make yet..

Sorry... that's very quick.  I'm going to be AFK for a couple days..

- Chris


On Jul 12, 2012, at 10:39 AM, Michael J Fork wrote:



Outside of the Etherpad (http://etherpad.openstack.org/FolsomComputeCells) and presentation referenced there (http://comstud.com/FolsomCells.pdf), are there additional details available on the architecture / implementation of Cells?

Thanks.

Michael

-------------------------------------------------
Michael Fork
Cloud Architect, Emerging Solutions
IBM Systems & Technology Group
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120713/5aa6bc27/attachment.html>


More information about the Openstack mailing list