<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<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>
</body>
</html>