[openstack-dev] Hyper-V meeting Minutes

Rochelle.Grober Rochelle.Grober at huawei.com
Tue Oct 15 21:48:28 UTC 2013





From: Vishvananda Ishaya [mailto:vishvananda at gmail.com]


Hi Everyone,



I've been following this conversation and weighing the different sides. This is a tricky issue but I think it is important to decouple further and extend our circle of trust.



When nova started it was very easy to do feature development. As it has matured the pace has slowed. This is expected and necessary, but we periodically must make decoupling decisions or we will become mired in overhead. We did this already with cinder and neutron, and we have discussed doing this with virt drivers in the past.

+1



We have a large number of people attempting to contribute to small sections of nova and getting frustrated with the process.  The perception of developers is much more important than the actual numbers here. If people are frustrated they are disincentivized to help and it hurts everyone. Suggesting that these contributors need to learn all of nova and help with the review queue is silly and makes us seem elitist. We should make it as easy as possible for new contributors to help.



Agreed.  I suspect the driver developers have more in common with each other, even across the different hypervisors, than they have with core Nova developers.  If Virt Drivers become their own project, the core reviewers will come from the driver community.  Core reviewers will not necessarily be reviewing the drivers from their team, but will understand the cogs and gears much better.  Plus, this puts all the driver folks on equal footing and incentivizes them to review each others' submissions.



I think our current model is breaking down at our current size and we need to adopt something more similar to the linux model when dealing with subsystems. The hyper-v team is the only one suggesting changes, but there have been similar concerns from the vmware team. I have no doubt that there are similar issues with the PowerVM, Xen, Docker, lxc and even kvm driver contributors.



Definitely heard the issue from the VMWare guys earlier in the summer.



In my opinion, nova-core needs to be willing to trust the subsystem developers and let go of a little bit of control. I frankly don't see the drawbacks.



I'm leaning towards giving control of the subtree to the team as the best option because it is simple and works with our current QA system. Alternatively, we could split out the driver into a nova subproject (2 below) or we could allow them to have a separate branch and do a trusted merge of all changes at the end of the cycle (similar to the linux model).



Option 1 or 2.  The last option would be much too painful for everyone and could cause all sorts of issues at crunch time.



I hope we can come to a solution to the summit that makes all of our contributors want to participate more. I believe that giving people more responsibility inspires them to participate more fully.



+1



--Rocky



Vish



On Oct 15, 2013, at 11:24 AM, Russell Bryant <rbryant at redhat.com> wrote:



> 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

>

> _______________________________________________

> OpenStack-dev mailing list

> OpenStack-dev at lists.openstack.org

> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131015/c534aef6/attachment.html>


More information about the OpenStack-dev mailing list