Open Stack

On 03/20/2014 07:01 PM, Michael Still wrote:
> Heya,
> 
> this came up in the defcore meeting today and I want to specifically
> call it out for your attention.
> 
> The lever that the defcore committee is using for compliance testing
> is tempest. There is a likelihood that telling vendors that their
> thing can only be defcore compliant if its tested with tempest will
> result in an increase in the number of tempest submissions, probably
> between the Icehouse release and about 90 days after.
> 
> Do you have any concerns with this I should be aware of?
> 
> Thanks,
> Michael

The heads up is good, I don't really have a lot of concerns there.
People just need to realize that Tempest runs like any other open stack
project, code needs to be of a certain quality, clear (in both code and
commit message on what it does and why), and self tested in the gate (or
some other 3rd party reporting so we have demonstrable verification that
the test runs and does what we think.) We'll also be rolling out a
qa-specs process mirroring much of what's happening in the nova-specs
process in a couple of weeks. So any area of substantial functional add
(vs. bug fix) will need an approved spec as well.

My only concern is going to be that folks will never have engaged in an
OpenStack project on any level are going to have a steep learning curve,
much like we saw on the 3rd party CI side. Especially culturally. Just
because a test is "really important" to a specific vendor, doesn't mean
it's good, or fits in tempest.

But that's true of new contributors everywhere. And honestly having
people got through the qa-spec process will probably help level set
what's expected out of contributions.

I also think it will be great to get the feedback from more folks about
any non intentional coupling we've got between Tempest and what happens
in the gate (i.e. defaults that only really work for specific devstack
envs). We've been trying to purge those out this cycle, especially
getting a lot of good feedback from HP folks running on their cloud end
points, and Red Hat running on their product, but I'm sure there is work
to be done.

	-Sean

-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20140321/33388f47/attachment.pgp>