<div dir="ltr">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.<div><br></div><div style>
-Mike</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 26, 2013 at 9:21 AM, Senhua Huang (senhuang) <span dir="ltr"><<a href="mailto:senhuang@cisco.com" target="_blank">senhuang@cisco.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div>+1 on the great work on initiating the design and implementation of a more structured and "manageable" provision manager. </div>
<div>+1 on the documentation.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Senhua</div>
<div><br>
</div>
<span>
<div style="border-right:medium none;padding-right:0in;padding-left:0in;padding-top:3pt;text-align:left;font-size:11pt;border-bottom:medium none;font-family:Calibri;border-top:#b5c4df 1pt solid;padding-bottom:0in;border-left:medium none">
<span style="font-weight:bold">From: </span><Karajgi>, Rohit <<a href="mailto:Rohit.Karajgi@nttdata.com" target="_blank">Rohit.Karajgi@nttdata.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Thursday, April 25, 2013 11:07 PM<br>
<span style="font-weight:bold">To: </span>OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><div><div class="h5"><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] Nova workflow management update<br>
</div></div></div><div><div class="h5">
<div><br>
</div>
<div>
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">+1x on the really well written plan and wikis.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">It just goes to show how important having a Structured State management is to Nova
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">for making it highly reliable and resilient across all APIs.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">We would eventually want to see Nova become
<i>Super</i>Nova!! </span><span style="font-size:11.0pt;font-family:Wingdings;color:#1f497d">J</span><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Regards,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Rohit<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif"> Adrian Otto [<a href="mailto:adrian.otto@rackspace.com" target="_blank">mailto:adrian.otto@rackspace.com</a>]
<br>
<b>Sent:</b> Friday, April 26, 2013 9:28 AM<br>
<b>To:</b> OpenStack Development Mailing List<br>
<b>Cc:</b> OpenStack Development Mailing List<br>
<b>Subject:</b> Re: [openstack-dev] Nova workflow management update<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Joshua,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<p class="MsoNormal">Adrian<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
On Apr 25, 2013, at 5:16 PM, "Joshua Harlow" <<a href="mailto:harlowja@yahoo-inc.com" target="_blank">harlowja@yahoo-inc.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">For those that missed the session & associated material.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">- <a href="https://etherpad.openstack.org/the-future-of-orch" target="_blank">https://etherpad.openstack.org/the-future-of-orch</a> (session details + discussion …)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">For example this is a possible diagram for the run_instance 'workflow' under this new scheme: <a href="http://imgur.com/sYOVz5X" target="_blank">http://imgur.com/sYOVz5X</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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" target="_blank">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). <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Some of the outcomes of that meeting I received that are relevant here:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">- HEAT may have a convection library (WIP - <a href="https://wiki.openstack.org/wiki/Convection" target="_blank">
https://wiki.openstack.org/wiki/Convection</a>) that this workflow restructuring can use. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">--- 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" target="_blank">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">--- 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" target="_blank">https://etherpad.openstack.org/task-system</a> (thx for the heat team for starting that
pad)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">- 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" target="_blank">https://wiki.openstack.org/wiki/StructuredStateManagement</a> (input
is welcome) <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">--- More details are at <a href="https://wiki.openstack.org/wiki/StructuredStateManagementDetails" target="_blank">https://wiki.openstack.org/wiki/StructuredStateManagementDetails</a> (WIP) since I didn't want to clutter the main page up…<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">--- Other thoughts of mine at <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-April/007881.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2013-April/007881.html</a> (with other code associated with it)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">- There was an ask on how conductor fits into this picture, this is still being worked out and discussed (thoughts welcome!)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">- 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)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">--- 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'. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">- More blueprints – I have started a few @ <a href="https://wiki.openstack.org/wiki/StructuredStateManagement#Blueprints" target="_blank">https://wiki.openstack.org/wiki/StructuredStateManagement#Blueprints</a> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">- Make a plan on how to get this into mainline, started this @ <a href="https://wiki.openstack.org/wiki/StructuredStateManagement#Plan_of_record" target="_blank">https://wiki.openstack.org/wiki/StructuredStateManagement#Plan_of_record</a> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Discussion is always welcome! I believe we can make this happen (and in all honesty
<i>must</i> make it happen).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I know there are others interested in this idea/solution, so if they want to chime in that would be wonderful :-)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">-Josh<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</blockquote>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><u></u><u></u></p>
</div>
</blockquote>
</div>
</div>
<br clear="both">
______________________________________________________________________<br>
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<br>
</div>
</div>
</div></div></span>
</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>