<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 24, 2015 at 7:10 AM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Tue, Mar 24, 2015 at 01:04:46PM +0000, Jeremy Stanley wrote:<br>
> On 2015-03-23 21:31:30 -0400 (-0400), Jay Pipes wrote:<br>
> > On Mon, Mar 23, 2015 at 09:35:50PM +0000, Jeremy Stanley wrote:<br>
> > > On 2015-03-23 15:15:18 -0400 (-0400), Jay Pipes wrote:<br>
> > > [...]<br>
> > > > I don't want it suppressed. I want the use of API extensions and the<br>
> > > > extension framework(s) to be completely dropped for all future<br>
> > > > API-affecting work.<br>
> > > [...]<br>
> > ><br>
> > > Perhaps controversial, but would it be worthwhile to propose to the<br>
> > > Defcore working group that future compliance requirements include<br>
> > > the absence of extensions to officially covered APIs?<br>
> ><br>
> > I don't understand what you're getting at, Jeremy. Could you elaborate?<br>
> ><br>
> > What do extensions have to do with future compliance requirements?<br>
><br>
> Defcore's focus is on establishing interoperability standards for<br>
> OpenStack deployments, to ease the end-user experience. Right now<br>
> its model depends on a whitelist of API features. As discussed many<br>
> times before and brought up again in this thread, when providers or<br>
> distributors "augment" OpenStack APIs to add their own special<br>
> features without implementing them upstream, this necessarily<br>
> creates interoperability issues.<br>
<br>
</span>Defcore's focus is on determining what "is OpenStack", w.r.t. what is<br>
brandable as OpenStack. It's focus is not on establishing interoperability<br>
standards.<br>
<span class=""><br></span></blockquote><div><br></div><div>I am not sure how you got to that conclusion, yes the defcore process has been very confusing and I am still not really sure what it was, but some part of it it *is* about interoperability/</div><div><br></div><div>Although our wiki does get out of date very easily, I think this still holds true:</div><div><br></div><div><i style="color:rgb(51,51,51);font-family:'Arial Unicode MS',Arial,sans-serif;font-size:14px;line-height:20px">DefCore sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."</i></div><div><i style="color:rgb(51,51,51);font-family:'Arial Unicode MS',Arial,sans-serif;font-size:14px;line-height:20px"><br></i></div><div><i style><font color="#333333" face="Arial Unicode MS, Arial, sans-serif"><span style="font-size:14px;line-height:20px"><a href="https://wiki.openstack.org/wiki/Governance/DefCoreCommittee">https://wiki.openstack.org/wiki/Governance/DefCoreCommittee</a></span></font></i> </div><div><br></div><div><br></div><div>Here is another source:</div><div><br></div><div><span style="color:rgb(55,55,55);font-family:'Helvetica Neue',Helvetica,Arial,sans-serif;font-size:15px;line-height:24.375px">"DefCore has a single goal expressed from two sides: 1) defining the “what is OpenStack” brand for Vendors and 2) driving interoperability between OpenStack installations.</span><span style="color:rgb(55,55,55);font-family:'Helvetica Neue',Helvetica,Arial,sans-serif;font-size:15px;line-height:24.375px"> "</span></div><div><br></div><div><a href="http://robhirschfeld.com/2015/02/26/openstack-defcore-accelerates-simplifies-with-clear-and-timely-guidelines-feedback/">http://robhirschfeld.com/2015/02/26/openstack-defcore-accelerates-simplifies-with-clear-and-timely-guidelines-feedback/</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> What I'm suggesting is that Defcore should not just specify which<br>
> API features need to be supported, but also specify that nonstandard<br>
> API features must not be added to the APIs its covering.<br>
<br>
</span>We're perilously close to re-igniting the "is OpenStack a set of APIs,<br>
or is OpenStack a set of implementations of those APIs" debate. A debate<br>
I'm happy to have, of course :)<br>
<br>
I'm really not a fan of the Defcore effort. This should come as no<br>
surprise to anyone. I've been quite blunt about my disdain for the focus<br>
on identifying which API things are mandatory and which are optional, in<br>
order to say some vendor's product "is OpenStack".<br>
<br>
That said, I'm not going to get in its way. If you think that Defcore<br>
should amend its compliancy guidelines to include the above, fine by me.<br>
<br>
Best,<br>
-jay<br>
<div class=""><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>