Difference between revisions of "NovaOrchestrationSpecForFolsom"
(talk) |
m (Text replace - "__NOTOC__" to "") |
||
| (4 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | |||
| − | |||
| − | + | <!-- ## page was renamed from [[NovaOrchestrationBrainStorming]] --> | |
| − | + | 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 20: | Line 19: | ||
Also another question? | 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. “ | + | “ 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 )... | + | 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: | As for the “proposal” part: | ||
| − | Would the api’s that are talked to be the message queue apis (are those documented/stable yet??). | + | 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...). |
| − | 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 ;) | This one ought to be a fun one ;) | ||
-Josh | -Josh | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Latest revision as of 23:30, 17 February 2013
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
