Open Stack

On 06/10/2014 10:09 AM, Duncan Thomas wrote:
> On 10 June 2014 15:07, Mark McLoughlin <markmc at 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 think maybe the issue people are having with the word "certification"
is that the way it's frequently used in the industry also implies a
certain level of support that we as a community can't/won't provide.  To
me it's a pretty strong word and I can understand the concern that users
might read more into it than we intend.

> 
>> I don't know what you mean be "others
>> imposing their idea of certification".
> 
> I mean that if some company or vendor starts claiming 'Product X is
> certified for use with cinder', that is bad for the cinder core team,
> since we didn't define what got tested or to what degree.

I wonder if they can even legally do that, but assuming they can what's
to stop them from claiming whatever crazy thing they want to, even if
there is a "certified" set of Cinder drivers?  No matter what term we
use to describe our testing process, someone is going to come up with
something that sounds similar but has no real meaning from our
perspective.  If we "certify" drivers, someone else will "verify" or
"validate" or whatever.

Without a legal stick to use for that situation I don't see that we can
really do much about the problem, other than to tell people they need to
talk to the company making the claims if they're having problems.

> 
> Whether we like it or not, when something doesn't work in cinder, it
> is rare for people to blame the storage vendor in their complaints.
> 'Cinder is broken' is what we hear (and I've heard it, even though
> what they meant is 'my storage vendor hasn't tested or updated their
> driver in two releases', that isn't what they /said/). 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.
> 
> If we run our own minimal certification program, which is what we've
> started doing (started with a script which did a test run and tried to
> require vendors to run it, that didn't work out well so we're now
> requiring CI integration instead), then we at least have the option of
> saying 'You're running an non-certified product, go talk to your
> vendor' when dealing with the cases we have no control over. Vendors
> that don't follow the CI & cert requirements eventually get their
> driver removed, that simple.

How would "You're using an untested product, go talk to your vendor" not
accomplish the same thing?

-Ben