Open Stack

Sorry for replying at the top....

Rocky - thanks for bringing this to the DefCore list

Jeremy - +1, the process has mechanisms to address these question and I 
believe your position (extensions are not required) is reflected in the 
2015.03 guideline.  I recall removing one of the capabilities at the 
DefCore face-to-face specifically for that reason.

Jay - it's not clear to me if you object to the fact that we are 
required by the by-laws to enforce the trademark or about the way that 
we've constructed the process to meet that obligation.  If the later, 
suggestions about improving are always welcome directly or via your TC 
DefCore delegates (Russell & Monty)

DefCore's weekly meeting is tomorrow at 9am PT.  Details: 
https://etherpad.openstack.org/p/DefCoreScale.9

Rob

On 03/24/2015 06:44 PM, Rochelle Grober wrote:
>
> Jeremy Stanley on March 24, 2015 07:28 wrote:
> On 2015-03-24 10:10:07 -0400 (-0400), Jay Pipes wrote:
> [...]
>> I'm really not a fan of the Defcore effort. This should come as no
>> surprise to anyone. I've been quite blunt about my disdain for the
>> focus on identifying which API things are mandatory and which are
>> optional, in order to say some vendor's product "is OpenStack".
> [...]
>
> Understandable--and I'm certainly no fan of bureaucracy and
> politicking--just pointing out that in the carrots-and-sticks bin we
> have trademarks as a potential carrot to encourage people running
> OpenStack commercially to further the goals of our community. If
> there is broad community support for the idea that standard
> OpenStack APIs should not be arbitrarily extended downstream because
> it hurts interoperability, then this might be one way to improve the
> situation. If there are other means to achieve this then they too
> should be considered, obviously.
>
> [Rockyg] Tl;dr.  Propose it to DefCore.  They might agree.  But they might have action items for developers to make it actionable on DefCore's part.
>
> Hey, it sounds like a reasonable request to me, and it's a large operator making the request for DefCore to recognize that extensions break interoperability.  Plus, Defcore specifically states that vendor specific code within OpenStack is not considered for inclusion in the Defcore capabilities/test/designated code sets.
>
> So then the questions become:
>
> * Are there any currently included capabilities that assume extensions work?
> * Are there any likely candidates for future Defcore sets that assume extensions work?
> * Will extensions be deprecated before capabilities requiring extensions are in the candidate pool?
> * Once extensions are deprecated, or it is known that nothing in Defcore sets include the ability to use extensions, are there tests which will validate that extensions are not part of the cloud under test?
>
> Something to think about, and if you are serious about limiting the negative effects of extensions, it is certainly worth proposing their elimination and/or restrictions on them to Defcore.
>
> And an FYI, APIs and tests are not chosen by DefCore because they are meaningful, but because they are measurable.  DefCore uses User Surveys (and who knows what else) to determine adoption rates of OpenStack "capabilities" that are then converted to APIs and tests, etc.  If you have a implementable ideas on how better to measure individual clouds/cloud products against the user communities' utilization, they'd love to hear from you.  No, really. DefCore wants to hear of better ways to ensure that clouds with the OpenStack trademark mean that user implementations on those clouds are portable across compliant vendors within the scope of what those vendors advertise.
>
> --rocky
>

-- 
   

Rob
____________________________
Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt