Open Stack

On 10/15/2013 12:52 PM, Peter Pouliot wrote:
> Hi Everyone,
> 
> 
> Here are the minutes from today’s hyper-v meeting.
> 
>  
> 
> Minutes:       
> http://eavesdrop.openstack.org/meetings/hyper_v/2013/hyper_v.2013-10-15-16.03.html
> 
> Minutes (text):
> http://eavesdrop.openstack.org/meetings/hyper_v/2013/hyper_v.2013-10-15-16.03.txt
> 
> Log:           
> http://eavesdrop.openstack.org/meetings/hyper_v/2013/hyper_v.2013-10-15-16.03.log.html

I read over the meeting notes and felt it was worth continuing the
discussion about the home of this driver.  I feel like we're not that
far from a conclusion, so we don't necessarily have to wait a few weeks
to talk about it.

In the meeting, the following options were metioned:

16:16:51 <alexpilotti> 1) we move the code somewhere else in a separate
repo (e.g.: cloudbase/nova)
16:17:26 <alexpilotti> 2) we move the code somewhere else in a separate
repo in OpenStack (e.g.: openstack/nova-driver-hyperv)
16:17:50 <alexpilotti> errata: on 1) it was meant to be:
cloudbase/nova-driver-hyperv
16:18:48 <alexpilotti> 3) we find a solution in which we get +2 rights
in our subtree: nova/virt/hyperv and nova/tests/virt/hyperv

I've thought about this quite a bit, and I no longer feel that #2 is an
option on the table.

#3 is possible, but it's not automatic.  It would happen the same way
anyone else gets on the core team (through participation and gaining
trust).  Staying in the tree, and eventually having someone with hyper-v
expertise on nova-core is the ideal outcome here, IMO.

#1 is certainly an option, and if that's what you want to do, I would
support that.  Honestly, after reading the full meeting log, it really
sounds like this is what you want.  You really do want the full control
that you get with having it be your own project, and that's fine.  I
feel that there are downsides too, but it's your call.  If you'd like to
go this route, just let me know so we can coordinate, and we can remove
the driver from the nova tree.

-- 
Russell Bryant