Open Stack

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