Open Stack

On Thu, 2014-02-13 at 19:35 -0700, Christopher Yeoh wrote:
> On Thu, 13 Feb 2014 21:10:01 -0500
> Sean Dague <sean at dague.net> wrote:
> > On 02/13/2014 08:28 PM, Christopher Yeoh wrote:
> > > On Thu, 13 Feb 2014 15:54:23 -0500
> > > Sean Dague <sean at dague.net> wrote:
> 
> > > 
> > > So one question I have around a global version is what happens when
> > > we have the following situation:
> > > 
> > > - Extension (not core) A is bumped to version 3, global version
> > > bumped to 3.01
> > > - Extension B (not core) is bumped to version 6, global version
> > > bumped to 3.02
> > > 
> > > but the deployer for $REASONS (perhaps stability/testing/whatever)
> > > really wants to deploy with version 2 of A but version 6 of B. 
> > > 
> > > With versioning just on the extensions individually they're ok, but
> > > I don't think there's any real sane way to get a global micro
> > > version calculated for this scenario that makes sense to the end
> > > user.
> > 
> > So there remains a question about extensions vs. global version. I
> > think a big piece of this is anything which is a "core" extension,
> 
> So to reduce confusion I've been trying to introduce the nomenclature of
> everything is a plugin. And then some plugins are compulsory (eg
> "core") and others are optional ("extensions")
> 
> > stops getting listed as an extension and instead is part of properly
> > core and using the global version.
> > 
> > How extensions impact global version is I think an open question. But
> > Nova OS API is actually really weird if you think about it relative to
> > other cloud APIs (ec2, gce, softlayer). We've defined it not as the
> > Nova API, but as a small core compute API, and many dozens optional
> > features, which every deployer makes decisions on what comes and goes.
> > 
> > I agree we need to think through a few things. But I think that if we
> > get to v3, only to have to do a ton more stuff for v4, and take 2 more
> > years to get there, we're in a world of hurt. The current model of API
> > revisions as giant big bangs isn't good for any one. A way to make an
> > API be able to grow over time, in a backwards compatible way, and some
> > mechanism to deprecate and remove a feature over time would be much
> > more advantageous to our consumers.
> > 
> 
> I agree we don't want to avoid another big bang version change for as
> long as we can. Given that we have extensions (and I know that some
> people really don't like that) however I'd be a lot more comfortable 
> if this minor global version was only bumped when there were changes to
> the core plugins or a plugin was added to the core (I don't think we
> can ever remove them from core within a major version). There should be
> a high bar on making any changes to core plugins (even though
> they are backwards compatible).
> 
> I'm also fine with core plugins not appearing in the /v3/extensions
> list. Its a simple enough change and agree that it will reduce
> confusion over interoperability between openstack clouds. 
> 
> Chris

Caveat: IANAND (I am not a nova dev) and i'm not familiar with nova's
plugins so i'm working with a standard definition of a plugin and define
for the rest of this email that: 
- An extension is something that adds paths or features to the API. 
- A plugin is code that is loaded to do some work.

To my mind talking of plugins is confusing the API with the
implementation. The sum total of the core plugins is the interface that
a project has to implement to be compatible with nova and is defined as
the core API. This API is the thing that we are versioning and that
should be done globally and semantically. If plugins are allowed to
directly define the API and some combination of plugins is loaded that
does not provided the API specified by the version then the server is in
error advertising that it supports that API version. 

An extension provides additional methods or data to the API (whether
this is loaded via plugin or always available). Being that extensions
are not covered by the API definition then they should provide there own
version discovery information. This means that an extension can define
an interface and that can co-exist with any version of the core API
(though i can definitely see the use case for this extension requires at
least this version of the API). By definition anything in the core API
is not an extension and should not be listed as such.

Version discovery could be done for extensions either as a part of GET /
but i think it makes sense for that to be part of the project specific
API (eg GET /v3/extensions) as that information may need to change in
future API versions. Also this is kind of outside the scope of what we
are talking about here. For now all we need is a way of determining core
API versions and then extension discovery is a subset of that. 


> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev