<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Mar 30, 2014 at 10:49 PM, Vui Chiap Lam <span dir="ltr"><<a href="mailto:vuichiap@vmware.com" target="_blank">vuichiap@vmware.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div style="font-size:12pt;font-family:'times new roman','new york',times,serif">

<div><p>Work has begun to convert a bunch of nested functions in VMwareVMOps::spawn()<br>to improve its {read,test,review}-ability. <br>(See <a href="https://blueprints.launchpad.net/nova/+spec/vmware-spawn-refactor" target="_blank">https://blueprints.launchpad.net/nova/+spec/vmware-spawn-refactor</a>)<br>

Much of it has already been hashed out in irc, so not much to add here.</p><p>But this work in very unlikely to address the other main issue with the method,<br>which is that it will continue to contain a large block of hard-to-follow code<br>

with a high level of branches unless something is done about it.</p><p>Presented here is a proposal to address the above-mentioned issue:<br><a href="https://etherpad.openstack.org/p/vmware-spawn-refactor-design" target="_blank">https://etherpad.openstack.org/p/vmware-spawn-refactor-design</a></p>

<p>The TL;DR version:</p><p>Through analyzing the current code as well several proposed functional changes<br>that would affect it, it was found that the areas of variability in the method<br>centers mostly around how the image is obtained, processed, and eventually<br>

employed by a newly created instance. So, the proposal is to refactor the<br>method by building some structure around those three areas of responsibilities.</p><p>The result should hopefully lead to shorter, more decoupled code, as well as<br>

facilitate future additions to those areas in a more isolated fashion.</p><p>A draft implementation of the proposal is at: <br><a href="https://review.openstack.org/#/c/82958/" target="_blank">https://review.openstack.org/#/c/82958/</a></p>

<p>I am interested to hear opinions on whether this is a reasonable approach to<br>take, as well as other suggestions/comments related to this topic.</p></div></div></div></blockquote><div>In Juno we are trying a new way to manage blueprints, please see<span style="font-size:13px;font-family:arial,sans-serif"> </span><a href="https://wiki.openstack.org/wiki/Blueprints#Creation" target="_blank" style="font-size:13px;font-family:arial,sans-serif">https://wiki.openstack.org/wiki/Blueprints#Creation</a> on how to propose your blueprint. We are now using gerrit and <a href="http://git.openstack.org/cgit/openstack/nova-specs/tree/">http://git.openstack.org/cgit/openstack/nova-specs/tree/</a> to do review the details of the blueprints.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div style="font-size:12pt;font-family:'times new roman','new york',times,serif">

<div><p>Cheers,<br>Vui</p><p><br></p></div></div></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></div>