Re: [openstack-dev] [nova][vmware] spawn() refactor: proposal to address branch complexity

[Joe Gordon]

On Sun, Mar 30, 2014 at 10:49 PM, Vui Chiap Lam  wrote:

> Work has begun to convert a bunch of nested functions in
> VMwareVMOps::spawn()
> to improve its {read,test,review}-ability.
> (See https://blueprints.launchpad.net/nova/+spec/vmware-spawn-refactor)
> Much of it has already been hashed out in irc, so not much to add here.
>
> But this work in very unlikely to address the other main issue with the
> method,
> which is that it will continue to contain a large block of hard-to-follow
> code
> with a high level of branches unless something is done about it.
>
> Presented here is a proposal to address the above-mentioned issue:
> https://etherpad.openstack.org/p/vmware-spawn-refactor-design
>
> The TL;DR version:
>
> Through analyzing the current code as well several proposed functional
> changes
> that would affect it, it was found that the areas of variability in the
> method
> centers mostly around how the image is obtained, processed, and eventually
> employed by a newly created instance. So, the proposal is to refactor the
> method by building some structure around those three areas of
> responsibilities.
>
> The result should hopefully lead to shorter, more decoupled code, as well
> as
> facilitate future additions to those areas in a more isolated fashion.
>
> A draft implementation of the proposal is at:
> https://review.openstack.org/#/c/82958/
>
> I am interested to hear opinions on whether this is a reasonable approach
> to
> take, as well as other suggestions/comments related to this topic.
>
In Juno we are trying a new way to manage blueprints, please see
https://wiki.openstack.org/wiki/Blueprints#Creation on how to propose your
blueprint. We are now using gerrit and
http://git.openstack.org/cgit/openstack/nova-specs/tree/ to do review the
details of the blueprints.


> Cheers,
> Vui
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][vmware] spawn() refactor: proposal to address branch complexity

[Vui Chiap Lam]

Work has begun to convert a bunch of nested functions in VMwareVMOps::spawn() 
to improve its {read,test,review}-ability. 
(See https://blueprints.launchpad.net/nova/+spec/vmware-spawn-refactor) 
Much of it has already been hashed out in irc, so not much to add here. 

But this work in very unlikely to address the other main issue with the method, 
which is that it will continue to contain a large block of hard-to-follow code 
with a high level of branches unless something is done about it. 

Presented here is a proposal to address the above-mentioned issue: 
https://etherpad.openstack.org/p/vmware-spawn-refactor-design 

The TL;DR version: 

Through analyzing the current code as well several proposed functional changes 
that would affect it, it was found that the areas of variability in the method 
centers mostly around how the image is obtained, processed, and eventually 
employed by a newly created instance. So, the proposal is to refactor the 
method by building some structure around those three areas of responsibilities. 

The result should hopefully lead to shorter, more decoupled code, as well as 
facilitate future additions to those areas in a more isolated fashion. 

A draft implementation of the proposal is at: 
https://review.openstack.org/#/c/82958/ 

I am interested to hear opinions on whether this is a reasonable approach to 
take, as well as other suggestions/comments related to this topic. 

Cheers, 
Vui 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev