On Thu, Feb 13, 2014 at 10:30 AM, Dean Troyer <dtro...@gmail.com> wrote: > On Thu, Feb 13, 2014 at 4:51 AM, Thierry Carrez <thie...@openstack.org> > wrote: > >> John Griffith wrote: >> > To add some controversy and keep the original intent of having only >> > known tested and working drivers in the Cinder release, I am going to >> > propose that any driver that has not submitted successful functional >> > testing by RC1 that that driver be removed. I'd at least like to see >> > driver maintainers try... if the test fails a test or two that's >> > something that can be discussed, but it seems that until now most >> > drivers just flat out are not even being tested. > > > +1 > >> >> I think there are multiple stages here. >> >> Stage 0: noone knows if drivers work >> Stage 1: we know the (potentially sad) state of the drivers that are in >> the release >> Stage 2: only drivers that pass tests are added, drivers that don't pass >> tests have a gap analysis and a plan to fix it >> Stage 3: drivers that fail tests are removed before release >> Stage 4: 3rd-party testing rigs must run tests on every change in order >> to stay in tree >> >> At the very minimum you should be at stage 1 for the Icehouse release, >> so I agree with your last paragraph. I'd recommend that you start the >> Juno cycle at stage 2 (for new drivers), and try to reach stage 3 for >> the end of the Juno release. > > > Are any of these drivers new for Icehouse? I think adding broken drivers in > Icehouse is a mistake. The timing WRT Icehouse release schedule is > unfortunate but so is shipping immature drivers that have to be supported > and possibly deprecated. Should new drivers that are lacking have some > not-quite-supported status to allow them to be removed in Juno if not > brought up to par? Or moved into cinder/contrib?
Yes, there are a boatload of new drivers being added. > > I don't mean to be picking on Cinder here, this seems to be recurring theme > in OpenStack. I think we benefit from strengthening the precedent that > makes it harder to get things in that are not ready even if the timing is > inconvenient. We're seeing this in project incubation and I think we all > benefit in the end. > > dt > > -- > > Dean Troyer > dtro...@gmail.com > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > I have another tact we can take on this in the interim. I like the contrib dir idea raised by Dean, a hybrid of that and the original proposal is we leave the certification optional, but we publish a certified driver list. We can also use the contrib idea with that as well, so the contrib dir would denote drivers that are not officially certified. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
