Difference between revisions of "NovaOrchestrationSpecForFolsom"

Revision as of 17:28, 22 March 2012

Previous Spec: http://wiki.openstack.org/NovaOrchestration

--Current Open Issues--

Notes from email discussions:

From: Joshua Harlow [ mailto:harlowja@yahoo-inc.com ] Sent: Tuesday, February 28, 2012 10:29 AM To: Sriram Subramanian; Jay Pipes; donald.d.dugger@intel.com ; mikeyp@lahondaresearch.org ; Sandy Walsh; nova-orchestration@lists.launchpad.net Cc: openstack-dev@yahoo-inc.com Subject: Re: Changes to http://wiki.openstack.org/NovaOrchestration

So just some questions on this.

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

On 2/28/12 1:47 AM, "Sriram Subramanian" < sriram@computenext.com > wrote: Hello all,

I took the liberty of updating the proposal to address some of the concerns raised by Sandy in the original proposal. I would appreciate feedback and get the ball rolling, so that we can have a solid blue print for Folsom.

Pardon my mistakes because this is my first attempt with blue prints/ openstack related proposals.

I will take up your feedback, and work on giving it a good shape that we would like it to be in.

thanks, -Sriram