<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body dir="auto">
<div>Works for me, I am not the best at writing sometimes :) there are a few areas to fill in that I plan on doing tommorow. </div>
<div><br>
</div>
<div>More help the better, thx much!</div>
<div><br>
Sent from my really tiny device...</div>
<div><br>
On Apr 25, 2013, at 9:00 PM, "Adrian Otto" <<a href="mailto:adrian.otto@rackspace.com">adrian.otto@rackspace.com</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div>Joshua,</div>
<div><br>
</div>
<div><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">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. </span>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div>
<div>Adrian</div>
</div>
<div><br>
On Apr 25, 2013, at 5:16 PM, "Joshua Harlow" <<a href="mailto:harlowja@yahoo-inc.com">harlowja@yahoo-inc.com</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div>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.</div>
<div><br>
</div>
<div>For those that missed the session & associated material.</div>
<div><br>
</div>
<div>- <a href="https://etherpad.openstack.org/the-future-of-orch">https://etherpad.openstack.org/the-future-of-orch</a> (session details + discussion …)</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>For example this is a possible diagram for the run_instance 'workflow' under this new scheme: <a href="http://imgur.com/sYOVz5X">http://imgur.com/sYOVz5X</a></div>
<div><br>
</div>
<div>Nttdata and y! have been pursuing how to refactor this in a well thought out design, and even have prototype code @ <a href="https://github.com/Yahoo/NovaOrc">https://github.com/Yahoo/NovaOrc</a> 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). </div>
<div><br>
</div>
<div>Some of the outcomes of that meeting I received that are relevant here:</div>
<div><br>
</div>
<div>- HEAT may have a convection library (WIP - <a href="https://wiki.openstack.org/wiki/Convection">
https://wiki.openstack.org/wiki/Convection</a>) that this workflow restructuring can use. </div>
<div>--- 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 <a href="http://aws.amazon.com/swf">http://aws.amazon.com/swf</a>). 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.</div>
<div>--- The documentation for my attempt at what I would like this central library to do where put @ <a href="https://etherpad.openstack.org/task-system">https://etherpad.openstack.org/task-system</a> (thx for the heat team for starting that pad)</div>
<div>- There was an ask to document more the overall design and how to accomplish it. I have started this @ <a href="https://wiki.openstack.org/wiki/StructuredStateManagement">https://wiki.openstack.org/wiki/StructuredStateManagement</a> (input is welcome) </div>
<div>--- More details are at <a href="https://wiki.openstack.org/wiki/StructuredStateManagementDetails">https://wiki.openstack.org/wiki/StructuredStateManagementDetails</a> (WIP) since I didn't want to clutter the main page up…</div>
<div>--- Other thoughts of mine at <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-April/007881.html">http://lists.openstack.org/pipermail/openstack-dev/2013-April/007881.html</a> (with other code associated with it)</div>
<div>- There was an ask on how conductor fits into this picture, this is still being worked out and discussed (thoughts welcome!)</div>
<div>- 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)</div>
<div>--- 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'. </div>
<div>- More blueprints – I have started a few @ <a href="https://wiki.openstack.org/wiki/StructuredStateManagement#Blueprints">https://wiki.openstack.org/wiki/StructuredStateManagement#Blueprints</a> </div>
<div>- Make a plan on how to get this into mainline, started this @ <a href="https://wiki.openstack.org/wiki/StructuredStateManagement#Plan_of_record">https://wiki.openstack.org/wiki/StructuredStateManagement#Plan_of_record</a> </div>
<div><br>
</div>
<div>Discussion is always welcome! I believe we can make this happen (and in all honesty
<i>must</i> make it happen).</div>
<div><br>
</div>
<div>I know there are others interested in this idea/solution, so if they want to chime in that would be wonderful :-)</div>
<div><br>
</div>
<div>-Josh</div>
<div><br>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>OpenStack-dev mailing list</span><br>
<span><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a></span><br>
<span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span><br>
</div>
</blockquote>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>OpenStack-dev mailing list</span><br>
<span><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a></span><br>
<span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span><br>
</div>
</blockquote>
</body>
</html>