Open Stack

Thanks Jay.

Whatever inaccuracies or errors you see with DriverLog, please file a bug
or an update request:
https://wiki.openstack.org/wiki/DriverLog#How_To:_Add_a_new_driver_to_DriverLog.


Also, we are more than happy to hear any suggestions on what information to
display and how to call what. As pointed out earlier in the thread, for the
exact reasons raised by Anita and Eoghan, there is no mention of certified
anywhere in DriverLog.

-Boris


On Tue, Jun 10, 2014 at 9:22 AM, Jay Pipes <jaypipes at gmail.com> wrote:

> Sorry, replied to wrong ML...
>
> -------- Original Message --------
> Subject: Re: [openstack-tc] [openstack-dev] use of the word certified
> Date: Tue, 10 Jun 2014 11:37:38 -0400
> From: Jay Pipes <jaypipes at gmail.com>
> To: openstack-tc at lists.openstack.org
>
> On 06/10/2014 09:53 AM, Sean Dague wrote:
>
>> On 06/10/2014 09:14 AM, Anita Kuno wrote:
>>
>>> On 06/10/2014 04:33 AM, Mark McLoughlin wrote:
>>>
>>>> On Mon, 2014-06-09 at 20:14 -0400, Doug Hellmann wrote:
>>>>
>>>>> On Mon, Jun 9, 2014 at 6:11 PM, Eoghan Glynn <eglynn at redhat.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>>  Based on the discussion I'd like to propose these options:
>>>>>>> 1. Cinder-certified driver - This is an attempt to move the
>>>>>>> "certification"
>>>>>>> to the project level.
>>>>>>> 2. CI-tested driver - This is probably the most accurate, at least
>>>>>>> for what
>>>>>>> we're trying to achieve for Juno: Continuous Integration of
>>>>>>> Vendor-specific
>>>>>>> Drivers.
>>>>>>>
>>>>>>
>>>>>> Hi Ramy,
>>>>>>
>>>>>> Thanks for these constructive suggestions.
>>>>>>
>>>>>> The second option is certainly a very direct and specific reflection
>>>>>> of
>>>>>> what is actually involved in getting the Cinder project's imprimatur.
>>>>>>
>>>>>
>>>>> I do like "tested."
>>>>>
>>>>> I'd like to understand what the foundation is planning for
>>>>> "certification" as well, to know how big of an issue this really is.
>>>>> Even if they aren't going to certify drivers, I have heard discussions
>>>>> around training and possibly other areas so I would hate for us to
>>>>> introduce confusion by having different uses of that term in similar
>>>>> contexts. Mark, do you know who is working on that within the board or
>>>>> foundation?
>>>>>
>>>>
>>>> http://blogs.gnome.org/markmc/2014/05/17/may-11-openstack-
>>>> foundation-board-meeting/
>>>>
>>>> Boris Renski raised the possibility of the Foundation attaching the
>>>> trademark to a verified, certified or tested status for drivers. It
>>>> wasn't discussed at length because board members hadn't been briefed in
>>>> advance, but I think it's safe to say there was a knee-jerk negative
>>>> reaction from a number of members. This is in the context of the
>>>> DriverLog report:
>>>>
>>>>    http://stackalytics.com/report/driverlog
>>>>    http://www.mirantis.com/blog/cloud-drivers-openstack-
>>>> driverlog-part-1-solving-driver-problem/
>>>>    http://www.mirantis.com/blog/openstack-will-open-source-
>>>> vendor-certifications/
>>>>
>>>> AIUI the "CI tested" phrase was chosen in DriverLog to avoid the
>>>> controversial area Boris describes in the last link above. I think that
>>>> makes sense. Claiming this CI testing replaces more traditional
>>>> certification programs is a sure way to bog potentially useful
>>>> collaboration down in vendor politics.
>>>>
>>> Actually FWIW the DriverLog is not posting accurate information, I came
>>> upon two instances yesterday where I found the information
>>> "questionable" at best. I know I questioned it. Kyle and I have agreed
>>> to not rely on the DriverLog information as it currently stands as a way
>>> of assessing the fitness of third party CI systems. I'll add some
>>> footnotes for those who want more details. [%%], [++], [&&]
>>>
>>>>
>>>> Avoiding dragging the project into those sort of politics is something
>>>> I'm really keen on, and why I think the word "certification" is best
>>>> avoided so we can focus on what we're actually trying to achieve.
>>>>
>>>> Mark.
>>>>
>>> I agree with Mark, everytime we try to 'abstract' away from logs and put
>>> an new interface on it, the focus moves to the interface and folks stop
>>> paying attention to logs. We archive and have links to artifacts for a
>>> reason and I think we need to encourage and support people to access
>>> these artifacts and draw their own conclusions, which is in keeping with
>>> our license.
>>>
>>> Copy/pasting Mark here:
>>> "Also AIUI "certification" implies some level of warranty or guarantee,
>>> which goes against the pretty clear language "WITHOUT WARRANTIES OR
>>> CONDITIONS OF ANY KIND" in our license :)" [**]
>>>
>>
>> Honestly, the bigger issue I've got at this point is that driverlog is
>> horribly inaccurate. Based on DriverLog you'd see that we don't test KVM
>> or QEMU at all, only XenAPI.
>>
>
> Then shouldn't the focus be on both reporting bugs to DriverLog [1] and
> fixing these inaccuracies? DriverLog doesn't use the term "certified"
> anywhere, for the record.
>
> It is an honest best effort to provide some insight into the testability
> of various drivers in the OpenStack ecosystem in a more up-to-date way
> than outdated wiki pages showing matrixes of support for something.
>
> It's an alpha project that can and will have bugs. I can absolutely
> guarantee you that the developers of the DriverLog project are more
> interested in getting accurate information shown in the interface than
> with any of the politics around the word "certified".
>
> Best,
>
> -jay
>
> [1] https://bugs.launchpad.net/driverlog
>
>
>
>
>
> _______________________________________________
> 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/20140610/5a4d7d50/attachment.html>