<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<div apple-content-edited="true"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br class="Apple-interchange-newline">
</div>
</span><br class="Apple-interchange-newline">
</span><br class="Apple-interchange-newline">
</div>
<br>
<div>
<div>On Oct 11, 2013, at 19:29 , Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>></div>
<div> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">On 10/11/2013 12:04 PM, John Griffith wrote:<br>
<blockquote type="cite"><br>
<br>
<br>
On Fri, Oct 11, 2013 at 9:12 AM, Bob Ball <<a href="mailto:bob.ball@citrix.com">bob.ball@citrix.com</a><br>
<<a href="mailto:bob.ball@citrix.com">mailto:bob.ball@citrix.com</a>>> wrote:<br>
<br>
<blockquote type="cite">-----Original Message-----<br>
From: Russell Bryant [mailto:rbryant@<a href="http://redhat.com">redhat.com</a><br>
</blockquote>
<<a href="mailto:rbryant@redhat.com">mailto:rbryant@redhat.com</a>>]<br>
<blockquote type="cite">Sent: 11 October 2013 15:18<br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
</blockquote>
<<a href="mailto:openstack-dev@lists.openstack.org">mailto:openstack-dev@lists.openstack.org</a>><br>
<blockquote type="cite">Subject: Re: [openstack-dev] [Hyper-V] Havana status<br>
<br>
<blockquote type="cite">As a practical example for Nova: in our case that would simply<br>
</blockquote>
</blockquote>
include the<br>
<blockquote type="cite">following subtrees: "nova/virt/hyperv" and "nova/tests/virt/hyperv".<br>
<br>
If maintainers of a particular driver would prefer this sort of<br>
autonomy, I'd rather look at creating new repositories. I'm<br>
</blockquote>
completely<br>
<blockquote type="cite">open to going that route on a per-driver basis. Thoughts?<br>
</blockquote>
<br>
I think that all drivers that are officially supported must be<br>
treated in the same way.<br>
<br>
If we are going to split out drivers into a separate but still<br>
official repository then we should do so for all drivers. This<br>
would allow Nova core developers to focus on the architectural side<br>
rather than how each individual driver implements the API that is<br>
presented.<br>
<br>
Of course, with the current system it is much easier for a Nova core<br>
to identify and request a refactor or generalisation of code written<br>
in one or multiple drivers so they work for all of the drivers -<br>
we've had a few of those with XenAPI where code we have written has<br>
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<br>
have; if drivers want to have the fast-development cycles uncoupled<br>
from core reviewers then they can be moved into an incubation<br>
project. When there is a suitable level of integration (and<br>
automated testing to maintain it of course) then they can graduate.<br>
I imagine at that point there will be more development of new<br>
features which affect Nova in general (to expose each hypervisor's<br>
strengths), so there would be fewer cases of them being restricted<br>
just to the virt/* tree.<br>
<br>
Bob<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<<a href="mailto:OpenStack-dev@lists.openstack.org">mailto:OpenStack-dev@lists.openstack.org</a>><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
I've thought about this in the past, but always come back to a couple of<br>
things.<br>
<br>
Being a community driven project, if a vendor doesn't want to<br>
participate in the project then why even pretend (ie having their own<br>
project/repo, reviewers etc). Just post your code up in your own github<br>
and let people that want to use it pull it down. If it's a vendor<br>
project, then that's fine; have it be a vendor project.<br>
<br>
In my opinion pulling out and leaving things up to the vendors as is<br>
being described has significant negative impacts. Not the least of<br>
which is consistency in behaviors. On the Cinder side, the core team<br>
spends the bulk of their review time looking at things like consistent<br>
behaviors, missing features or paradigms that are introduced that<br>
"break" other drivers. For example looking at things like, are all the<br>
base features implemented, do they work the same way, are we all using<br>
the same vocabulary, will it work in an multi-backend environment. In<br>
addition, it's rare that a vendor implements a new feature in their<br>
driver that doesn't impact/touch the core code somewhere.<br>
<br>
Having drivers be a part of the core project is very valuable in my<br>
opinion. It's also very important in my view that the core team for<br>
Nova actually has some idea and notion of what's being done by the<br>
drivers that it's supporting. Moving everybody further and further into<br>
additional private silos seems like a very bad direction to me, it makes<br>
things like knowledge transfer, documentation and worst of all bug<br>
triaging extremely difficult.<br>
<br>
I could go on and on here, but nobody likes to hear anybody go on a<br>
rant. I would just like to see if there are other alternatives to<br>
improving the situation than fragmenting the projects.<br>
</blockquote>
<br>
Really good points here. I'm glad you jumped in, because the underlying<br>
issue here applies well to other projects (especially Cinder and Neutron).<br>
<br>
So, the alternative to the split official repos is to either:<br>
<br>
1) Stay in tree, participate, and help share the burden of maintenance<br>
of the project<br>
<br>
</blockquote>
<div><br>
</div>
<div>Which means getting back to the status quo with all the problems we had. I hope we'll be able to find something better than that.</div>
<div><br>
</div>
<blockquote type="cite">or<br>
<br>
2) Truly be a vendor project, and to make that more clear, split out<br>
into your own (not nova) repository.<br>
</blockquote>
<div><br>
</div>
<div>I explained in my previous relpy some points about why it would be IMO totally counterproductive to have a fork outside of OpenStack.</div>
<div>
<div>Our goal is to have more and more independent community members contributing to the driver and forking would definitely go in the opposite direction. What would be the official version of the driver at that point? The old copy in Nova that nobody practically
mantains or the shiny new version that a vendor mantains w/o community contribution? </div>
<div><br>
</div>
</div>
<div>I agreed on your initial proposal: a separate OpenStack project, independent from Nova. What's the difference at this point from the "split out into your own" option that you are suggesting now from a management perspective?</div>
<div><br>
</div>
<div>Talking about new community involvements, newcomers are getting very frustrated to have to wait for weeks to get a meaningful review and I cannot blame them if they don't want to get involved anymore after the first patch!</div>
<div>This makes appear public bureocracy here in eastern Europe a lightweight process in comparison! :-)</div>
<div><br>
</div>
<div>Let me add another practical reason about why a separate OpenStack project would be a good idea:</div>
<div><br>
</div>
<div>Anytime that we commit a driver specific patch, a lot of Tempests tests are executed on Libvirt and XenServer (for Icehouse those will be joined by another pack of CIs, including Hyper-V).</div>
<div>On the jenkins side, we have to wait for regression tests that have nothing to do with the code that we are pushing. During the H3 push, this meant waiting for hours and hoping not to have to issue the 100th "recheck / revery bug xxx".</div>
<div><br>
</div>
<div>A separate project would obviously include only the required tests and be definitely more lightweight, offloading quite some work from the SmokeStack / Jenkins job for everybody's happiness.</div>
<div><br>
</div>
<div><br>
</div>
<blockquote type="cite"><br>
#2 really isn't so bad if that's what you want, and it honestly sounds<br>
like this may be the case for the Hyper-V team. You could still be very<br>
close to the OpenStack community by using the same tools. Use<br>
stackforge for the code (same gerrit, jenkins, etc), and have your own<br>
launchpad project. If you go that route, you get all of the control you<br>
want, but the project is still very closely tied to the rest of the code<br>
in the OpenStack community.<br>
<br>
-- <br>
Russell Bryant<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>
</blockquote>
</div>
<br>
</body>
</html>