On Tue, Mar 24, 2015 at 7:10 AM, Jay Pipes <[email protected]> wrote:
> On Tue, Mar 24, 2015 at 01:04:46PM +0000, Jeremy Stanley wrote: > > On 2015-03-23 21:31:30 -0400 (-0400), Jay Pipes wrote: > > > On Mon, Mar 23, 2015 at 09:35:50PM +0000, Jeremy Stanley wrote: > > > > On 2015-03-23 15:15:18 -0400 (-0400), Jay Pipes wrote: > > > > [...] > > > > > I don't want it suppressed. I want the use of API extensions and > the > > > > > extension framework(s) to be completely dropped for all future > > > > > API-affecting work. > > > > [...] > > > > > > > > Perhaps controversial, but would it be worthwhile to propose to the > > > > Defcore working group that future compliance requirements include > > > > the absence of extensions to officially covered APIs? > > > > > > I don't understand what you're getting at, Jeremy. Could you elaborate? > > > > > > What do extensions have to do with future compliance requirements? > > > > Defcore's focus is on establishing interoperability standards for > > OpenStack deployments, to ease the end-user experience. Right now > > its model depends on a whitelist of API features. As discussed many > > times before and brought up again in this thread, when providers or > > distributors "augment" OpenStack APIs to add their own special > > features without implementing them upstream, this necessarily > > creates interoperability issues. > > Defcore's focus is on determining what "is OpenStack", w.r.t. what is > brandable as OpenStack. It's focus is not on establishing interoperability > standards. > > 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/ Although our wiki does get out of date very easily, I think this still holds true: *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."* *https://wiki.openstack.org/wiki/Governance/DefCoreCommittee <https://wiki.openstack.org/wiki/Governance/DefCoreCommittee>* Here is another source: "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. " http://robhirschfeld.com/2015/02/26/openstack-defcore-accelerates-simplifies-with-clear-and-timely-guidelines-feedback/ > > What I'm suggesting is that Defcore should not just specify which > > API features need to be supported, but also specify that nonstandard > > API features must not be added to the APIs its covering. > > We're perilously close to re-igniting the "is OpenStack a set of APIs, > or is OpenStack a set of implementations of those APIs" debate. A debate > I'm happy to have, of course :) > > 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". > > That said, I'm not going to get in its way. If you think that Defcore > should amend its compliancy guidelines to include the above, fine by me. > > Best, > -jay > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
