Open Stack

+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!! :)

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<mailto: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) 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<mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130426/df1a0c4d/attachment.html>