Open Stack

Just to add some additional background information.  Today, if you wish to qualify for the OpenStack Powered logo (see attached) as well as other associated trademark rights (i.e. how you name your product if it includes the word “OpenStack” in it) . You must meet these criteria.  Note that this list of requirement is rather old, dating back to a time when we had a LOT fewer projects and capabilities, and thus, in my view, the sooner we can implement something better, the better, even if that something better isn’t perfect (as few things are).

On the substantive questions raised throughout this thread on the right policies, I am very interested to hear from users like Tim on what really matters wrt interop, since in my mind that’s job #1 of this whole exercise.


Current Requirements Language:
---------------------

a.  A primary purpose of your product must be to run a functioning operational instance of the OpenStack software.

b.  Your product must:

i. upon its launch, include the entirety of the OpenStack Compute (Nova) code from either of the latest two releases and associated milestones, and

ii. upon its launch, include the entirety of the OpenStack Object Storage (Swift) code from either of the latest two releases and associated milestones, and

iii. expose the associated OpenStack APIs published on http://www.openstack.org without modification.

c. You must clearly state which OpenStack projects and versions are used to set customer expectations, in a way that is conspicuous to customers.

d. As of January 1st, 2012, your product must pass any Faithful Implementation Test Suite (FITS) defined by the Technical Committee that will be made available on http://www.openstack.org/FITS, to verify that you are implementing a sufficiently current and complete version of the software (and exposing associated APIs) to ensure compatibility and interoperability. Your product will be required to pass the current FITS test on an annual basis, which will generally require you to be running either of the latest two software releases. 

—————--------------------


So today we require you to have 100% of Nova + the Nova APIs.  and 100% of Swift + the Swift APIs.  Now one might point out that this lacks some level of specificity to be crystal clear, but I think what Rob and team have been trying to do over the past few months is to bring a lot more specificity to whatever comes next, which is both an ambitious and admirable goal.  Both in terms of 1) what APIs we mean specifically 2) what tests we mean you to pass specifically associated with those APIs and 3) what code requirements, specifically, are required (and looking beyond just Nova and Swift to the whole list of possible projects … which are now thought of as “capabilities” more so than “projects” to take a more user centric view).  

So how will the contract language re: requirements change as defcore, the board, and community arrive at a consensus on “what’s next”?  Here’s what i expect:

It is my expectation that A) will stay as-is.  "A primary purpose of your product must be to run a functioning operational instance of the OpenStack software.” We could tweak it but I think it’s pretty clear.
It is my expectation that c) will stay as-is "You must clearly state which OpenStack projects and versions are used to set customer expectations, in a way that is conspicuous to customers.”
And that everything under b, which deals with capabilities/code/apis today will be re-written to reflect the required capabilities, APIs, and code inclusion once those are approved (note that Icehouse is the first expected enforceable version, as the Havana stuff being discussed today is “advisory” meaning it wouldn’t be a contract requirement). I am working on this language in conjunction with our trademark attorney (with placeholders for the actual things that are in or out, pending a decision there) and will socialize it with the ecosystem and defcore.  We might actually want to take the specificity out of the agreement itself and point instead to a web page where the details are posted, so that we can get this moving faster and not over burden the agreement itself.
My expectation is that d) will be re-written to more accurately reflect the expected testing requirements and mechanisms.  Frankly, if we just put the tests  and steps up on the page OpenStack.org/FITS then I’m not sure how much change this language needs. That said, we should decide if this is still the standard for freshness and re-testing we want to have "Your product will be required to pass the current FITS test on an annual basis, which will generally require you to be running either of the latest two software releases. “

The benefit of sticking with as much of the language in D) as possible is that it has been in agreements for years, and is thus socialized and actually agreed to by many many companies already.  I’m not against re-writing it but let’s do so for a good reason.  One thing that does not seem to jive with the current reality is the statement that the FITS test is “defined by the Technical Committee.  Would it be more accurate to say that we are now looking to the Board to define the test?  I don’t have a dog in that fight, just wanting to have the agreements reflect the direction we’re going, so we’re ready to cut over when it’s time.











> On Aug 19, 2014, at 12:50 AM, Tom Fifield <tom at openstack.org> wrote:
> 
> I'm pretty much blocked out until the ops meetup is over (say 1st
> September or so) - when is that board meeting again?
> 
> but anyway, here's what I'm thinking:
> 
> Simple webapp that does away with everything but components, explaining
> the complex bits only in context for what a potential trademark
> applicant is trying to do with components.
> 
> so, two parts:
> 
> 1) the form (static html) - what is the activity {run a cloud, make a
> storage product etc}, what trademark {powered, compatible, etc}, and
> which components are being used
> 
> 2) the result page (a template, filled in by some code based on the form
> selections)
> 
> that talks about whether the components they've ticked are enough, and
> also about what they're allowed to do with those components.
> Ideally, each component name would link off to a dedicated page for that
> component explaining the 'designated sections' and required API things.
> 
> mockups attached - very, very rough!
> 
> 
> I'd propose to create this and circulate it so that the community can
> understand the impact of the suggested designated sections before the
> board meeting.
> 
> 
> 
> Regards,
> 
> 
> Tom
> 
> On 15/08/14 14:04, Rob_Hirschfeld at Dell.com wrote:
>> Tom / Josh,
>> 
>> 
>> 
>> We can update the examples; however, I think that we could use some help
>> here.  You can I are very close to the material and make assumptions
>> about reader knowledge when explaining it.
>> 
>> 
>> 
>> It would be helpful to have someone (Tom?) with a fresh perspective take
>> a pass at it.
>> 
>> 
>> 
>> Rob
>> 
>>> -----Original Message-----
>>> From: Tom Fifield [mailto:tom at openstack.org]
>>> Sent: Thursday, August 14, 2014 7:52 PM
>>> To: Joshua McKenty
>>> Cc: defcore-committee at lists.openstack.org
>>> Subject: Re: [OpenStack-DefCore] Please review, results from
>>> Designated Sections review w/ recommendations. +1s needed
>>> 
>>> All good with me :) Though, I would note the timeframe here is short.
>>> We obviously want the community to be able to understand the real
>>> impact of these suggested designated suggestions and comment on them
>>> well before any board meeting, so revisited sooner the better IMO!
>>> 
>>> 
>>> Regards,
>>> 
>>> 
>>> Tom
>>> 
>>> 
>>> On 15/08/14 10:47, Joshua McKenty wrote:
>>>> Tom, those examples we're put together before the trademark was
>>>> changed
>>> by the foundation staff. We may need to revisit those practical concerns.
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>>> On Aug 14, 2014, at 7:43 PM, Tom Fifield wrote:
>>>>> 
>>>>> Hit send too soon :) I also didn't find any "practical
>>>>> implementation concerns" in those slides - that would also be
>>>>> appreciated :)
>>>>> 
>>>>> 
>>>>>>>> I'm also interested in any practical implementation concerns you
>>>>>>>> think can arise based on the below suggestions.
>>>>>>>> 
>>>>>>>> For example, in the case of an "OpenStack Powered" cloud that
>>>>>>>> offers an object store that is not swift, would they be
>>>>>>>> recommended/required to denote that actually that particular bit
>>>>>>>> was
>>> not "Openstack Powered"?
>>>>>>>> 
>>>>>>>> I could see that being confusing for users, and my guess is
>>>>>>>> there might be some similar cases that should be managed :)
>>>>> 
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> 
>>>>> Tom
>>>>> 
>>>>>> On 15/08/14 10:41, Tom Fifield wrote:
>>>>>> Hi Rob,
>>>>>> 
>>>>>> Thanks for the reply :)
>>>>>> 
>>>>>> I actually find these pretty complicated - is there a chance for
>>>>>> some simpler ones?
>>>>>> 
>>>>>> 
>>>>>> Regards,
>>>>>> 
>>>>>> 
>>>>>> Tom
>>>>>> 
>>>>>>> On 15/08/14 09:59, Rob_Hirschfeld at Dell.com wrote:
>>>>>>> Tom,
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> I agree!
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Josh and I did a presentation with examples in ATL
>>>>>>> (http://www.confreaks.com/videos/3695-openstacksummitatl2014-core
>>>>>>> -
>>> v
>>>>>>> ia-crowd-sourcing-defcores-tempest-in-a-docker-container-tcup
>>>>>>> ) and I gave an updated version at OSCON
>>>>>>> (http://www.slideshare.net/rhirschfeld/oscon-2014-def-core-review
>>>>>>> )
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> These are also discussed on my blog at
>>>>>>> http://www.slideshare.net/rhirschfeld/oscon-2014-def-core-review
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Please let me know if those examples help explain the use of the
>>>>>>> mark better.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Thanks
>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: Tom Fifield [mailto:tom at openstack.org]
>>>>>>>> Sent: Thursday, August 14, 2014 6:14 PM
>>>>>>>> To: defcore-committee at lists.openstack.org
>>>>>>>> Subject: Re: [OpenStack-DefCore] Please review, results from
>>>>>>>> Designated Sections review w/ recommendations. +1s needed
>>>>>>>> 
>>>>>>>> Hi Rob,
>>>>>>>> 
>>>>>>>> Can you provide a few example uses of the commercial marks based
>>>>>>>> on
>>> below?
>>>>>>>> 
>>>>>>>> eg "I can call my cloud "OpenStack Powered" without regard to
>>>>>>>> the use of Keystone."
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I'm also interested in any practical implementation concerns you
>>>>>>>> think can arise based on the below suggestions.
>>>>>>>> 
>>>>>>>> For example, in the case of an "OpenStack Powered" cloud that
>>>>>>>> offers an object store that is not swift, would they be
>>>>>>>> recommended/required to denote that actually that particular bit
>>>>>>>> was
>>> not "Openstack Powered"?
>>>>>>>> 
>>>>>>>> I could see that being confusing for users, and my guess is
>>>>>>>> there might be some similar cases that should be managed :)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Tom
>>>>>>>> 
>>>>>>>>> On 15/08/14 04:54, Rob_Hirschfeld at Dell.com wrote:
>>>>>>>>> DefCore,
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> We had a small turn out and very good discussions that were
>>>>>>>>> able to produce clear guidance for Designated Sections (see
>>>>>>>>> below). We also reviewed the Havana capabilities from the board
>>>>>>>>> meeting and the 10 designated sections principles approved by
>>>>>>>>> email. Finally, we setup a calendar for community review
>>>>>>>>> leading up to the September Board meeting
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Here are the recommendations:
>>>>>>>>> 
>>>>>>>>> · Havana Nova is by default designated except scheduler,
>>>>>>>>> filter, drivers, API extensions and networking.
>>>>>>>>> 
>>>>>>>>> · Havana Swift has no designated code due to lack of consensus
>>>>>>>>> (see principles)
>>>>>>>>> 
>>>>>>>>> · Havana Keystone is not designated.
>>>>>>>>> 
>>>>>>>>> · Havana Glance designated sections are the API implementation
>>>>>>>>> code and domain model.
>>>>>>>>> 
>>>>>>>>> · Havana Cinder designated sections are the API implementation
>>>>>>>>> code
>>>>>>>>> 
>>>>>>>>> · Havana Neutron has no designated sections.
>>>>>>>>> 
>>>>>>>>> · Havana Heat is not a core capability, no position at this time.
>>>>>>>>> 
>>>>>>>>> · Havana Horizon is not a core capability, no position at this
>> time.
>>>>>>>>> 
>>>>>>>>> · other projects do not are not core capabilities and are not
>>>>>>>>> reviewed at this time.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Please contribute to a discussion or +1
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Rob
>>>>>>>>> 
>>>>>>>>> *______________________________*
>>>>>>>>> 
>>>>>>>>> *Rob Hirschfeld*
>>>>>>>>> 
>>>>>>>>> Sr. Distinguished Cloud Solution Architect
>>>>>>>>> 
>>>>>>>>> *Dell*| Cloud Edge, Data Center Solutions**
>>>>>>>>> 
>>>>>>>>> *cell*+1 512 909-7219 *blog* robhirschfeld.com, *twitter*
>>>>>>>>> @zehicle
>>>>>>>>> 
>>>>>>>>> Please note, I am based in the CENTRAL (-6) time zone
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> Defcore-committee mailing list
>>>>>>>> Defcore-committee at lists.openstack.org
>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-comm
>>>>>>>> it
>>>>>>>> tee
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Defcore-committee mailing list
>>>>>> Defcore-committee at lists.openstack.org
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-commit
>>>>>> te
>>>>>> e
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Defcore-committee mailing list
>>>>> Defcore-committee at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committ
>>>>> ee
>>> 
>>> 
>>> _______________________________________________
>>> Defcore-committee mailing list
>>> Defcore-committee at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
>> 
> 
> <defcore-page1.png><defcore-page2.png><defcore-page3.png>_______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20140819/767d2c3f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openstack-powered-sample.png
Type: image/png
Size: 39880 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20140819/767d2c3f/attachment-0001.png>