On Thu, 13 Feb 2014 21:10:01 -0500 Sean Dague <s...@dague.net> wrote: > On 02/13/2014 08:28 PM, Christopher Yeoh wrote: > > On Thu, 13 Feb 2014 15:54:23 -0500 > > Sean Dague <s...@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev