Open Stack

I have a couple of questions that came to mind while I was reviewing the wiki and figuring out what to put into the etherpad.

First, it seems that all of the "core capabilities" are exposed by a ["single"|"set of"] tempest tests. This means that 6.13 ("Consumers must have a way to determine how the system is different from reference (posted, discovered, etc)") must be something that is able to be determined by tempest, right?

If that is the case, here is my question: How does this work? Doesn't tempest do functional tests of the API? So what if a "designated section" isn't visible to the API? How is it tested by tempest and how is it therefore in or out of core?

These questions lead me to one of two possibilities: (1) "OpenStack Core" is only related to an external API or (2) Tempest will significantly change to do more invasive tests[1]. Can someone provide some guidance here?

(I hesitate to provide a specific use case here, although I do have one, because I'd like the answer to the general case.)

Second, and more of a high-level issue, section 8.1 says that there will be an OpenStack body which recommends which tests are "must-pass". Section 9.1 implies that the DefCore team has some influence here (the recommendations pass through this group). Who is this group, and why is it not automatically the core-team/PTLs (passing through the TC)?

--John



[1] By "invasive tests" I mean tests that know about (and perhaps modify) internal cluster state in the course of testing. These types of tests are extremely valuable, but are not what tempest does today, AFAIK.


On Mar 21, 2014, at 6:41 AM, Anne Gentle <anne at openstack.org> wrote:

> 
> 
> 
> On Fri, Mar 21, 2014 at 4:10 AM, Thierry Carrez <thierry at openstack.org> wrote:
> Michael Still wrote:
> > So, the defcore committee just had a meeting and I have to say it was
> > a lot more productive than the previous one. I'm sure the recording
> > will appear on YouTube at some point, but I am not sure when that will
> > be.
> >
> > There is a desire to have a voice chat to interactively produce an
> > etherpad that contains straw man designated sections for the various
> > integrated projects. I personally think this is a good idea, because I
> > think it will be more productive than yet another email thread.
> >
> > So... Who is available for either of these time slots next week?
> >
> >  * Wednesday 26 March at 8pm UTC
> >  * Friday 28 March at 8pm UTC
> 
> Shouldn't this call also be directed to the integrated projects PTLs,
> rather than just the TC members ? IMHO the PTLs are the final authority
> for producing this information, with the TC providing guidance and
> encouraging some homogeneity.
> 
> Here is a list of people that need to be looped in (Icehouse release):
> David Lyle (Horizon)
> Dolph Mathews (Keystone)
> John Dickinson (Swift)
> Julien Danjou (Ceilometer)
> Mark Washenberger (Glance)
> Michael Basnight (Trove)
> Steve Baker (Heat)
> 
> The other integrated projects PTLs (Nova, Cinder, Oslo, Neutron) also
> seat on the TC.
> 
> 
> Thanks for the list, Thierry. Adding them to this thread. (There's no all-PTL mailing list I should use, right?)
> 
> The request: we're looking for designated sections of your program's code to help define criteria for "core definition" where core definition is part of our governance docs at https://wiki.openstack.org/wiki/Governance/CoreDefinition. 
> 
> Who wants it: The board members working on core definition
> 
> What does it get them: Forward movement on defining the OpenStack mark use policies
> How will they know if they have it: The etherpad at https://etherpad.openstack.org/p/openstack-designated-sections will have your project's name in it with simple definitions of what parts of your code base should be run. (Do not overthink this: simple outlines will suffice.)
> 
> When do they need it by: 3/31 (I know this is a busy time for everyone with the release. Please raise your hand if you need help, we will find it for you.)
> 
> Who might be exempt: We do not need all projects to designate sections, only the ones that are likely to have capabilities flagged by required tests. If you think yours lands in this exempt category, just ask. 
> 
> What happens if this doesn't get done: We continue to struggle with the definition of an OpenStack cloud. Probably someone else will define for you (which is also likely just fine).
> 
> Let me know if this request outline is useful and feel free to ask any questions as you go.
> 
> Anne
>  
> --
> Thierry Carrez (ttx)
> 
> _______________________________________________
> OpenStack-TC mailing list
> OpenStack-TC at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-tc/attachments/20140321/76ab0e60/attachment.pgp>