Open Stack

+1 on all the work done by Joshua and Rohit so far.
I think in a very highly scalable solutions like Nova, we need a framework to resume/retry/rollback various stages of vm in a structured way.
I can see this is driving in that direction.

- Tushar

>-----Original Message-----
>From: Mike Wilson [mailto:geekinutah at gmail.com]
>Sent: Friday, April 26, 2013 8:30 AM
>To: OpenStack Development Mailing List
>Subject: Re: [openstack-dev] Nova workflow management update
>
>Very exciting to see this happening. Structured state management is
>sorely needed. I also like the plan of attack, tackling creation of an
>instance first is a good way to feel this one out.
>
>-Mike
>
>
>On Fri, Apr 26, 2013 at 9:21 AM, Senhua Huang (senhuang)
><senhuang at cisco.com> wrote:
>
>
>	+1 on the great work on initiating the design and implementation
>of a more structured and "manageable" provision manager.
>	+1 on the documentation.
>
>	Having a state management separated from resource selection is
>very helpful for group scheduling, cross compute/storage/network
>scheduling, as well as improved migration solution. It makes Nova more
>modular, easier to track and reasoning about errors, and easier to
>scale.
>
>	Thanks,
>	Senhua
>
>
>	From: <Karajgi>, Rohit <Rohit.Karajgi at nttdata.com>
>	Reply-To: OpenStack Development Mailing List <openstack-
>dev at lists.openstack.org>
>	Date: Thursday, April 25, 2013 11:07 PM
>	To: OpenStack Development Mailing List <openstack-
>dev at lists.openstack.org>
>
>	Subject: Re: [openstack-dev] Nova workflow management update
>
>
>
>	+1x on the really well written plan and wikis.
>
>
>
>	It just goes to show how important having a Structured State
>management is to Nova
>
>	for making it highly reliable and resilient across all APIs.
>
>
>
>	We would eventually want to see Nova become SuperNova!! J
>
>
>
>	Regards,
>
>	Rohit
>
>
>
>
>
>	From: Adrian Otto [mailto:adrian.otto at rackspace.com]
>	Sent: Friday, April 26, 2013 9:28 AM
>	To: OpenStack Development Mailing List
>	Cc: OpenStack Development Mailing List
>	Subject: Re: [openstack-dev] Nova workflow management update
>
>
>
>	Joshua,
>
>
>
>	I'm one of the Rackers helping to add development resources to
>Convection. I also work on the OASIS CAMP TC as an editor. I want to
>help create a reusable task system that helps Nova, Heat, and many other
>OpenStack projects. I am happy to see this progressing. The recent
>collaboration among the Nova and Heat/Convection teams is very
>encouraging. Thanks for all your efforts to form a sensible written
>plan.
>
>
>
>	I'd like to take an editorial pass through the
>StructuredStateManagement wiki, and help tighten up the definitions a
>bit. Some wording changes may avoid some of the more overloaded
>technical terms (but there are practically no pure ones left). I'm
>planning to make a few edits to the wiki page (so there will be diffs),
>but if another approach is preferred, I'm open to that too. Please
>advise.
>
>
>
>	Thanks,
>
>
>
>	Adrian
>
>
>	On Apr 25, 2013, at 5:16 PM, "Joshua Harlow" <harlowja at yahoo-
>inc.com> wrote:
>
>		Since I wanted to make sure everyone was aware of this,
>since some of you might have missed the summit session and I'd like
>discussions so we can land code in havana.
>
>
>
>		For those that missed the session & associated material.
>
>
>
>		- https://etherpad.openstack.org/the-future-of-orch
>(session details + discussion ...)
>
>
>
>		The summary of what I am trying to do is to move nova away
>from having ad-hoc tasks and move it toward having a central entity (not
>a single entity, but a central one, one that can be horizontally
>scalable) which can execute these tasks on-behalf of nova-compute. This
>central entity (a new orchestrator or conductor...) would centrally manage
>the workflow that nova goes through when completing an API request and
>would do so in a organized, controlled and resumable manner (it would
>also support rollbacks and more...). The reasons why what exists currently
>may not be optimal/good are listed in that etherpad, so I won't repeat
>them here.
>
>
>
>		For example this is a possible diagram for the run_instance
>'workflow' under this new scheme: http://imgur.com/sYOVz5X
>
>
>
>		Nttdata and y! have been pursuing how to refactor this in a
>well thought out design, and even have prototype code @
>https://github.com/Yahoo/NovaOrc which has some of these changes (see
>the last 4-10 commits). The prototype was shown in the session but feel
>free to check out the code, if you setup with that code - its based on
>stable/grizzly, it should run (note that no external api changes
>occurred).
>
>
>
>		Some of the outcomes of that meeting I received that are
>relevant here:
>
>
>
>		- HEAT may have a convection library (WIP -
>https://wiki.openstack.org/wiki/Convection
><https://wiki.openstack.org/wiki/Convection> ) that this workflow
>restructuring can use.
>
>		--- Note: If this code is created quickly (creating a solid
>core) then it seems like we can use this code in nova itself and start
>restructuring nova into using this code. This of course then allows HEAT
>to use said library also, and nova as well (and likely creates future
>capabilities for something like http://aws.amazon.com/swf). The talk
>about this I think is just being started, but it seems like a solid core
>can be created in a week or two.
>
>		--- The documentation for my attempt at what I would like
>this central library to do where put @
>https://etherpad.openstack.org/task-system (thx for the heat team for
>starting that pad)
>
>		- There was an ask to document more the overall design and
>how to accomplish it. I have started this @
>https://wiki.openstack.org/wiki/StructuredStateManagement (input is
>welcome)
>
>		--- More details are at
>https://wiki.openstack.org/wiki/StructuredStateManagementDetails (WIP)
>since I didn't want to clutter the main page up...
>
>		--- Other thoughts of mine at
>http://lists.openstack.org/pipermail/openstack-dev/2013-
>April/007881.html (with other code associated with it)
>
>		- There was an ask on how conductor fits into this picture,
>this is still being worked out and discussed (thoughts welcome!)
>
>		- There was talk about how live migration/resizing can take
>advantage of such a workflow like system to become more secure (details
>on another email)
>
>		--- This one involves planning, where imho i would like
>nova/heat groups to focus on this core library, and when adjusting the
>live migration/resize path they should use said core library. If not a
>core library then the prototype code I have created above (along with
>nttdata) can be altered to focus on those paths instead of the initial
>prototype path of 'run_instance'.
>
>		- More blueprints - I have started a few @
>https://wiki.openstack.org/wiki/StructuredStateManagement#Blueprints
>
>		- Make a plan on how to get this into mainline, started
>this @
>https://wiki.openstack.org/wiki/StructuredStateManagement#Plan_of_record
>
>
>
>		Discussion is always welcome! I believe we can make this
>happen (and in all honesty must make it happen).
>
>
>
>		I know there are others interested in this idea/solution,
>so if they want to chime in that would be wonderful :-)
>
>
>
>		-Josh
>
>
>
>		_______________________________________________
>		OpenStack-dev mailing list
>		OpenStack-dev at lists.openstack.org
>		http://lists.openstack.org/cgi-
>bin/mailman/listinfo/openstack-dev
>
>
>	__________________________________________________________________
>____
>	Disclaimer:This email and any attachments are sent in strictest
>confidence for the sole use of the addressee and may contain legally
>privileged, confidential, and proprietary data. If you are not the
>intended recipient, please advise the sender by replying promptly to
>this email and then delete and destroy this email and any attachments
>without any further use, copying or forwarding
>
>
>	_______________________________________________
>	OpenStack-dev mailing list
>	OpenStack-dev at lists.openstack.org
>	http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>

______________________________________________________________________
Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data.  If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding