Open Stack

There are a couple of additional things we are working on driver
verification front that, I believe, it is now time to socialize with the
dev community:

1. In addition to the scare tactic of deprecating the code for those that
don't test their drivers, we also want to implement a carrot-tactic of
granting a trademark privilege to those that do. Specifically, storage
vendors that have achieved Stage 4 or Thierry's ladder below, will have the
right granted by the openstack foundation to publically endorse themselves
as "OpenStack Verified Block Storage Vendors." I've spoken to the vast
majority of the foundation board members about this as well as Mark and
Jonathan, and, everybody appears to be onboard. I plan to formally have
a foundation board discussion on this topic during the upcoming March 3rd
board meeting and would like to gather the feedback of the dev community on
this. So please.... feedback away...

2. As a stepping stone to #1, we are working on implementing an interactive
dashboard (not just for devs, but for OpenStack users as well) that
will display the results of driver tests against trunk and stable dot
releases pulled directly from CI even stream (mock attached). The way we
are thinking of implementing this right now is next to each of the drivers
in https://wiki.openstack.org/wiki/CinderSupportMatrix, specify if the
compatibility is "self-reported" or "verified." Verified will be a link to
the dashboard for a particular driver kinda like in the mock.

-Boris


>
> On Thu, Feb 13, 2014 at 10:30 AM, Dean Troyer <dtroyer at gmail.com> wrote:
> > On Thu, Feb 13, 2014 at 4:51 AM, Thierry Carrez <thierry at 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
> > dtroyer at gmail.com
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at 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 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/20140221/e1532528/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: driver_test_dashboard.png
Type: image/png
Size: 43931 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140221/e1532528/attachment-0001.png>