nova-orchestration team mailing list archive
Mailing list archive
Re: Changes to http://wiki.openstack.org/NovaOrchestration
You can checkout the last meeing log at:
"Censeo Toto nos in Kansa esse decisse." - D. Gale
From: Yun Mao [mailto:yunmao@xxxxxxxxx]
Sent: Friday, March 02, 2012 12:40 PM
To: Sriram Subramanian
Cc: Joshua Harlow; Jay Pipes; Dugger, Donald D; mikeyp@xxxxxxxxxxxxxxxxxxx; Sandy Walsh; nova-orchestration@xxxxxxxxxxxxxxxxxxx; openstack-dev@xxxxxxxxxxxxx
Subject: Re: [Nova-orchestration] Changes to http://wiki.openstack.org/NovaOrchestration
Hi guys, is there a irc log somewhere I could take a look to catch up? Thanks,
On Thu, Mar 1, 2012 at 12:50 PM, Sriram Subramanian
> Hello All:
> Sorry I won't be able to join the IRC meeting today due to a scheduling
> conflict. I have updated the wiki page with a link
> (http://wiki.openstack.org/NovaOrchestrationBrainStorming) to our
> discussions via email which can be used for discussions today if needed.
> From: Joshua Harlow [mailto:harlowja@xxxxxxxxxxxxx]
> Sent: Tuesday, February 28, 2012 10:29 AM
> To: Sriram Subramanian; Jay Pipes; donald.d.dugger@xxxxxxxxx;
> mikeyp@xxxxxxxxxxxxxxxxxxx; Sandy Walsh;
> Cc: openstack-dev@xxxxxxxxxxxxx
> 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 ;)
> On 2/28/12 1:47 AM, "Sriram Subramanian" <sriram@xxxxxxxxxxxxxxx> 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.
> Mailing list: https://launchpad.net/~nova-orchestration
> Post to : nova-orchestration@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~nova-orchestration
> More help : https://help.launchpad.net/ListHelp