<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Oct 11, 2013 at 9:12 AM, Bob Ball <span dir="ltr"><<a href="mailto:bob.ball@citrix.com" target="_blank">bob.ball@citrix.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> -----Original Message-----<br>
> From: Russell Bryant [mailto:<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>]<br>
> Sent: 11 October 2013 15:18<br>
> To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
> Subject: Re: [openstack-dev] [Hyper-V] Havana status<br>
><br>
</div><div class="im">> > As a practical example for Nova: in our case that would simply include the<br>
> following subtrees: "nova/virt/hyperv" and "nova/tests/virt/hyperv".<br>
><br>
</div><div class="im">> If maintainers of a particular driver would prefer this sort of<br>
> autonomy, I'd rather look at creating new repositories. I'm completely<br>
> open to going that route on a per-driver basis. Thoughts?<br>
<br>
</div>I think that all drivers that are officially supported must be treated in the same way.<br>
<br>
If we are going to split out drivers into a separate but still official repository then we should do so for all drivers. This would allow Nova core developers to focus on the architectural side rather than how each individual driver implements the API that is presented.<br>
<br>
Of course, with the current system it is much easier for a Nova core to identify and request a refactor or generalisation of code written in one or multiple drivers so they work for all of the drivers - we've had a few of those with XenAPI where code we have written has been pushed up into Nova core rather than the XenAPI tree.<br>
<br>
Perhaps one approach would be to re-use the incubation approach we have; if drivers want to have the fast-development cycles uncoupled from core reviewers then they can be moved into an incubation project. When there is a suitable level of integration (and automated testing to maintain it of course) then they can graduate. I imagine at that point there will be more development of new features which affect Nova in general (to expose each hypervisor's strengths), so there would be fewer cases of them being restricted just to the virt/* tree.<br>
<span class="HOEnZb"><font color="#888888"><br>
Bob<br>
</font></span><div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div><div class="gmail_extra"><div class="gmail_default" style="font-family:'courier new',monospace">I've thought about this in the past, but always come back to a couple of things.</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">Being a community driven project, if a vendor doesn't want to participate in the project then why even pretend (ie having their own project/repo, reviewers etc). Just post your code up in your own github and let people that want to use it pull it down. If it's a vendor project, then that's fine; have it be a vendor project.</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">In my opinion pulling out and leaving things up to the vendors as is being described has significant negative impacts. Not the least of which is consistency in behaviors. On the Cinder side, the core team spends the bulk of their review time looking at things like consistent behaviors, missing features or paradigms that are introduced that "break" other drivers. For example looking at things like, are all the base features implemented, do they work the same way, are we all using the same vocabulary, will it work in an multi-backend environment. In addition, it's rare that a vendor implements a new feature in their driver that doesn't impact/touch the core code somewhere.</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">Having drivers be a part of the core project is very valuable in my opinion. It's also very important in my view that the core team for Nova actually has some idea and notion of what's being done by the drivers that it's supporting. Moving everybody further and further into additional private silos seems like a very bad direction to me, it makes things like knowledge transfer, documentation and worst of all bug triaging extremely difficult.</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">I could go on and on here, but nobody likes to hear anybody go on a rant. I would just like to see if there are other alternatives to improving the situation than fragmenting the projects.</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">John</div><div class="gmail_default" style="font-family:'courier new',monospace">
<br></div><div class="gmail_default" style="font-family:'courier new',monospace"><br></div></div></div>