<font size=2 face="sans-serif">I'd like to see the powervm driver fall
into that first category. We don't nearly have the rapid development
that the hyper-v driver does, but we do have some out of tree stuff anyway
simply because it hasn't landed upstream yet (DB2, config drive support
for the powervm driver, etc), and maintaining that out of tree code is
not fun. So I definitely don't want to move out of tree.</font>
<br>
<br><font size=2 face="sans-serif">Given that, I think at least I'm trying
to contribute overall [1][2] by doing reviews outside my comfort zone,
bug triage, fixing bugs when I can, and because we run tempest in house
(with neutron-openvswitch) we find issues there that I get to push patches
for.</font>
<br>
<br><font size=2 face="sans-serif">Having said all that, it's moot for
the powervm driver if we don't get the CI hooked up in Icehouse and I completely
understand that so it's a top priority.</font>
<br>
<br><font size=2 face="sans-serif"><br>
[1] </font><a href="http://stackalytics.com/?release=havana&metric=commits&project_type=openstack&module=&company=&user_id=mriedem"><font size=3 color=blue><u>http://stackalytics.com/?release=havana&metric=commits&project_type=openstack&module=&company=&user_id=mriedem</u></font></a><font size=3>
</font>
<br><font size=2 face="sans-serif">[2] </font><a href="https://review.openstack.org/#/q/reviewer:6873+project:openstack/nova,n,z"><font size=3 color=blue><u>https://review.openstack.org/#/q/reviewer:6873+project:openstack/nova,n,z</u></font></a><font size=3>
</font>
<br><font size=2 face="sans-serif"><br>
</font>
<br><font size=1 face="Arial">Thanks,</font>
<br>
<br><font size=3 color=#8f8f8f face="Arial"><b>MATT RIEDEMANN</b></font><font size=1 face="Arial"><br>
Advisory Software Engineer<br>
Cloud Solutions and OpenStack Development</font>
<table width=680 style="border-collapse:collapse;">
<tr height=8>
<td width=680 colspan=2 style="border-style:solid;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;">
<hr>
<tr valign=top height=8>
<td width=418 style="border-style:solid;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><font size=1 color=#4181c0 face="Arial"><b>Phone:</b></font><font size=1 color=#5f5f5f face="Arial">
1-507-253-7622</font><font size=1 color=#4181c0 face="Arial"> | <b>Mobile:</b></font><font size=1 color=#5f5f5f face="Arial">
1-507-990-1889</font><font size=1 color=#4181c0 face="Arial"><b><br>
E-mail:</b></font><font size=1 color=#5f5f5f face="Arial"> </font><a href=mailto:mriedem@us.ibm.com target=_blank><font size=1 color=#5f5f5f face="Arial"><u>mriedem@us.ibm.com</u></font></a>
<td width=261 style="border-style:solid;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;">
<div align=right><img src=cid:_1_06A6EFEC06A6EA58005D586686257C01 width=83 height=30 alt=IBM><font size=1 color=#5f5f5f face="Arial"><br>
<br>
3605 Hwy 52 N<br>
Rochester, MN 55901-1407<br>
United States</font></div></table>
<br>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Russell Bryant <rbryant@redhat.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">openstack-dev@lists.openstack.org,
</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">10/11/2013 11:33 AM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [openstack-dev]
[Hyper-V] Havana status</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>On 10/11/2013 12:04 PM, John Griffith wrote:<br>
> <br>
> <br>
> <br>
> On Fri, Oct 11, 2013 at 9:12 AM, Bob Ball <bob.ball@citrix.com<br>
> <</font></tt><a href=mailto:bob.ball@citrix.com><tt><font size=2>mailto:bob.ball@citrix.com</font></tt></a><tt><font size=2>>>
wrote:<br>
> <br>
> > -----Original Message-----<br>
> > From: Russell Bryant [</font></tt><a href=mailto:rbryant@redhat.com><tt><font size=2>mailto:rbryant@redhat.com</font></tt></a><tt><font size=2><br>
> <</font></tt><a href=mailto:rbryant@redhat.com><tt><font size=2>mailto:rbryant@redhat.com</font></tt></a><tt><font size=2>>]<br>
> > Sent: 11 October 2013 15:18<br>
> > To: openstack-dev@lists.openstack.org<br>
> <</font></tt><a href="mailto:openstack-dev@lists.openstack.org"><tt><font size=2>mailto:openstack-dev@lists.openstack.org</font></tt></a><tt><font size=2>><br>
> > Subject: Re: [openstack-dev] [Hyper-V] Havana status<br>
> ><br>
> > > As a practical example for Nova: in our case
that would simply<br>
> include the<br>
> > 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>
> completely<br>
> > open to going that route on a per-driver basis.
Thoughts?<br>
> <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>
> OpenStack-dev@lists.openstack.org<br>
> <</font></tt><a href="mailto:OpenStack-dev@lists.openstack.org"><tt><font size=2>mailto:OpenStack-dev@lists.openstack.org</font></tt></a><tt><font size=2>><br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><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>
<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>
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>
<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>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
<br>
</font></tt>
<br>