Open Stack

Two very quick answers, and then I’ll let Rob elaborate.

Essentially, the definition of core is the *intersection* of these two concepts - designated sections, and must-have capabilities. Thus, if a project (such as Swift) has *any* capabilities which have been determined to be must-have, then *all* of the designated sections must be included in any implementation. However, both the application of the capabilities testing using RefStack, and the presence of designated sections of code, is a self-certification effort at this time. E.g., the foundation does not own any responsibility of AUDITING that these two things are going on. And particularly, the tests are not intended to introspect the designated sections.

Second question: Simply put, the primary reason for the Board of Directors to exist, is to determine the definition of core. They have voted to delegate the responsibility to prepare a recommendation for that definition to the DefCore committee. The previous vote (to use designated sections as part of that definition) was the lesser consensus that could be reached after Rob and Alan spent some hundreds of hours with hundreds of community members, looking for a simpler and more straightforward consensus.

The ultimate responsibility to determine a designated sections approach and recommend it to the board, rests on the DefCore committee. However, since it’s primarily a technical matter, we’ve asked the TC and the PTLs to weigh in on it. If the recommendations of the TC and of the PTLs don’t line up, then I’m not sure what that means.
--

Joshua McKenty
Chief Technology Officer
Piston Cloud Computing, Inc.
+1 (650) 242-5683
+1 (650) 283-6846
http://www.pistoncloud.com

"Oh, Westley, we'll never survive!"
"Nonsense. You're only saying that because no one ever has."

On Mar 21, 2014, at 3:49 PM, John Dickinson <me at not.mn> wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20140321/610e1896/attachment.html>