
<html><body><div style="font-family: times new roman, new york, times, serif; font-size: 12pt; color: #000000"><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 https://blueprints.launchpad.net/nova/+spec/vmware-spawn-refactor)<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>https://etherpad.openstack.org/p/vmware-spawn-refactor-design</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>https://review.openstack.org/#/c/82958/</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><p>Cheers,<br>Vui</p><p><br></p></div></div></body></html>