Difference between revisions of "NovaOrchestrationSpecForFolsom"
(Using this as placeholder for Folsom discussions) |
|||
| Line 3: | Line 3: | ||
Previous Spec: http://wiki.openstack.org/NovaOrchestration | Previous Spec: http://wiki.openstack.org/NovaOrchestration | ||
| − | -- | + | --"Ideas"--- |
| − | + | 1) Orchestration - would be good to have it as a separate service (like nova-orchestration) | |
| + | 2) Orchestration service provides state management with client side APIs | ||
| − | + | --"Current Open Issues"-- | |
| − | |||
| − | |||
For the steps part: | For the steps part: | ||
| Line 32: | Line 31: | ||
-Josh | -Josh | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Revision as of 17:30, 2 April 2012
Previous Spec: http://wiki.openstack.org/NovaOrchestration
--"Ideas"---
1) Orchestration - would be good to have it as a separate service (like nova-orchestration) 2) Orchestration service provides state management with client side APIs
--"Current Open Issues"--
For the steps part:
“Talk to all of the zones and come up with a build plan for the request. “
Is this really needed/valid anymore (anything referring to zones actually).
It almost seems like you could have the orchestration part talk to a reservation system (in the abstract) through a defined protocol. Then there needs to be a way to “lock” those nodes, then provision to those nodes, and if a failure occurs the lock needs to be released and another reservation system request needs to be made to find a new location. This locking part seems to be pretty important (and it seems like coordination would need to be made with this reservation system and the orchestrator to perform this, zookeeper anyone?)
Also another question?
“ Essentially we are spinning up 100 little state machines and then we have a master state machine overseeing each of the sub-tasks. “
What is the data structures that are better for this? It almost seems like here we would have the orchestration “engine” that can handle a state transition up to a single point, then a checkpoint happens with the database, then if that “engine” fails another “engine” can take over that orchestration task. Are there projects in the opensource world that do something similar, I would think hadoop would have them ( http://kdpeterson.net/blog/2009/11/hadoop-workflow-tools-survey.html )...
As for the “proposal” part:
Would the api’s that are talked to be the message queue apis (are those documented/stable yet??). Also the comment about “Note: I don't know if orchestration needs to be a standalone service”. Please make it a standalone service. There has been to much confusion about combining roles of things that shouldn’t be combined (or fix it by renaming the scheduler...).
This one ought to be a fun one ;)
-Josh
