[openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

Joe Gordon joe.gordon0 at gmail.com
Tue Mar 24 14:20:04 UTC 2015


On Tue, Mar 24, 2015 at 7:10 AM, Jay Pipes <jaypipes at gmail.com> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150324/c749db90/attachment.html>


More information about the OpenStack-dev mailing list