On 10 June 2014 17:53, Mark McLoughlin <mar...@redhat.com> wrote:
> On Tue, 2014-06-10 at 16:09 +0100, Duncan Thomas wrote:
>> On 10 June 2014 15:07, Mark McLoughlin <mar...@redhat.com> wrote:
>> > Exposing which configurations are actively "tested" is a perfectly sane
>> > thing to do. I don't see why you think calling this "certification" is
>> > necessary to achieve your goals.
>> What is certification except a formal way of saying 'we tested it'? At
>> least when you test it enough to have some degree of confidence in
>> your testing.
>> That's *exactly* what certification means.
> I disagree. I think the word has substantially more connotations than
> simply "this has been tested".
> http://lists.openstack.org/pipermail/openstack-dev/2014-June/036963.html

Ok, so I think you have a high opinion of certification programs in
general than my experiences have led me to expect, but I'm starting to
see your point.


>> Since cinder,
>> and therefore cinder-core, is going to get the blame, I feel we should
>> try to maintain some degree of control over the claims.
> I'm starting to see where you're coming from, but I fear this
> "certification" thing will make it even worse.
> Right now you can easily shrug off any responsibility for the quality of
> a third party driver or an untested in-tree driver. Sure, some people
> may have unreasonable expectations about such things, but you can't stop
> people being idiots. You can better communicate expectations, though,
> and that's excellent.
> But as soon as you "certify" that driver cinder-core takes on a
> responsibility that I would think is unreasonable even if the driver was
> tested. "But you said it's certified!"
> Is cinder-core really ready to take on responsibility for every issue
> users see with "certified" drivers and downstream OpenStack products?

I think we de facto have a lot of that responsibility, whether we like
it or not. You might be right about the work certification making it
worse, I don't think it does, but at least I'm managed to explain my
position clearly and I think it has been understood.

> If it's an out-of-tree driver then we say "talk to your vendor".
> If it's an in-tree driver, those actively maintaining the driver provide
> "best effort community support" like anything else.
> If it's an in-tree driver and isn't being actively maintained, and "best
> effort community support" isn't being provided, then we need a way to
> communicate that unmaintained status. The level of testing it receives
> is what we currently see as the most important aspect, but it's not the
> only aspect.

In cinder, I expect a driver removal patch to be the communication
method. I think that view (with varying degrees of communication,
carrot and stick before hand to get a better resolution if possible)
is pretty much agreed by most of cinder core.

> Mark.

Thanks for your time and repeated replies, I think we are now both
aware of what the other person is saying and why, which is the point I
wanted to get to. It seems like the weight of opinion is against me,
so I'll go quiet on the subject... it is in the end a subjective
matter. Thanks to Anita for opening the discussion.

Duncan Thomas

OpenStack-dev mailing list

Reply via email to