grizzly: Support for cells in Compute (nova)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
openstack-manuals |
Fix Released
|
Medium
|
Lorin Hochstein |
Bug Description
Gathering information about cells for documenting it after it lands:
Blueprint (likely most up-to-date): http://
Etherpad (http://
Presentation referenced there (http://
http://
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[
(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..
Changed in openstack-manuals: | |
milestone: | none → grizzly |
status: | New → Confirmed |
status: | Confirmed → New |
tags: | removed: docimpact |
Changed in openstack-manuals: | |
assignee: | nobody → Lorin Hochstein (lorinh) |
main cells code has been added.