Open Stack

Just to clarify the language, when you say “BOTH an API tests and to require upstream contributions”, the latter is a reference to requiring the use of [designated sections of] the code for those who wish to use the brand commercially, not actually a requirement to contribute code upstream. This might be lost on the casual reader so I wanted to flag it.



On Mar 24, 2014, at 8:59 AM, <Rob_Hirschfeld at Dell.com> <Rob_Hirschfeld at Dell.com> wrote:

> Thanks Josh & John,
>  
> It’s important to realize that DefCore is starting a process that will take several cycles to complete (we are working on Havana now) and we are trying to motivate/anticipate community engagement in that process.  Specifically, we recognize that Tempest is not nearly as complete as we’d like for this task but it is a starting point.  It looks like the first pass will be very API focused; however, that may change as we get experience and react.  That’s why we are working on a PROCESS not just a set of tests.  We expect that the very process of using a test driven core definition will help close the gaps over time.
>  
> I see that part of the Board’s job is to manage the brand.  Our feedback from community is that not knowing “what is required” and “making clouds interoperate” are top brand issues.  We believe that DefCore process addresses those priorities.
>  
> One thing to note is that there were two top (potentially conflicting) objectives that surfaced leading up to DefCore being formed.  We wanted BOTH an API tests and to require upstream contributions.  That lead us to needing both a test suite AND designated sections.  We specifically stated that the designated sections requirement would be honor system until there was reason to believe we need more enforcement.  The purpose of designated sections is to encourage upstreaming, not to create a policing authority. 
>  
> The goal is to have DefCore be a workable compromise for now that solves our immediate problems without creating worse issues.  If someone has a perfect solution, I’d love to hear about it.  I’m sure revisit it as we get more concrete on the must-pass test selection & designated section processes.
>  
>  
> From: Joshua McKenty [mailto:joshua at pistoncloud.com] 
> Sent: Friday, March 21, 2014 7:02 PM
> To: John Dickinson
> Cc: Anne Gentle; Thierry Carrez; david.lyle at hp.com; Dolph Mathews; Julien Danjou; mark.washenberger; Michael Basnight; Steve Baker; Michael Still; openstack-tc at lists.openstack.org; defcore-committee; Hirschfeld, Rob
> Subject: Re: [openstack-tc] Meeting to develop a straw man set of designated sections
>  
> 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
> 
>  
>  
> _______________________________________________
> 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/openstack-tc/attachments/20140324/3efe5f77/attachment-0001.html>