Open Stack

On 21 March 2015 at 18:12, Joe Gordon <joe.gordon0 at gmail.com> wrote:
> On Sat, Mar 21, 2015 at 8:31 AM, Monty Taylor <mordred at inaugust.com> wrote:
>> On 03/21/2015 01:21 AM, Chris Friesen wrote:
>> > Hi,
>> >
>> > I've recently been playing around a bit with API microversions and I
>> > noticed something that may be problematic.
>> >
>> > The way microversions are handled, there is a monotonically increasing
>> > MAX_API_VERSION value in "nova/api/openstack/api_version_request.py".
>> > When you want to make a change you bump the minor version number and
>> > it's yours. End-users can set the microversion number in the request to
>> > indicate what they support, and all will be well.
>> >
>> > The issue is that it doesn't allow for OpenStack providers to add their
>> > own private microversion(s) to the API.  They can't just bump the
>> > microversion internally because that will conflict with the next
>> > microversion bump upstream (which could cause problems when they
>> > upgrade).
>> >
>> > In terms of how to deal with this, it would be relatively simple to just
>> > bump the major microversion number at the beginning of each new
>> > release.  However, that would make it difficult to backport
>> > bugfixes/features that use new microversions since they might overlap
>> > with private microversions.
>> >
>> > I think a better solution might be to expand the existing microversion
>> > API to include a third digit which could be considered a "private"
>> > microversion, and provide a way to check the third digit separate from
>> > the other two.  That way providers would have a way to add custom
>> > features in a backwards-compatible way without worrying about colliding
>> > with upstream code.
>>
>> I would vote that we not make this pleasant or easy for vendors who are
>> wanting to add a feature to the API. As a person who uses several clouds
>> daily, I can tell you that a vendor chosing to do that is VERY mean to
>> users, and provides absolutely no value to anyone, other than allowing
>> someone to make a divergent "differentiated" fork.
>>
>> Just don't do it. Seriously. It makes life very difficult for people
>> trying to consume these things.
>>
>> The API is not the place for divergence.
>
>
> In fact we have made vendorization of the API hard on purpose, see the
> microversion spec for details: https://review.openstack.org/#/c/127127
>
> To quote Jay Pipes from that review:
>
> -1 for vendor flag
>
> Recommend getting rid of the vendor: specification entirely. The point of
> standardizing our APIs is to make them standard, not to allow vendorization.
> API extensions were an idea designed (in part) to allow vendorization. And
> we've seen how that works out.
>
> Let's take a hard stand and say "this is the OpenStack Compute API" and be
> done with it. If RAX or HP Cloud or Frobnozzle Cloud wants to have a
> separate but different API, then they should call it something else, because
> it's not the OpenStack Compute API

+1 for the same Compute API everywhere.

The micro-versions work should make it easier to evolve the API more
quickly, so it help reduce the need for deploying API changes that you
can't get upstreamed quickly enough.

We are not stopping vendor specific API endpoints, that appear
separately in the keystone catalog. Certainly, thats where I hope
things that would never go upstream will move to.

Its worth noting, we do have the "experimental" flag:
"
The first header specifies the version number of the API which was
executed. Experimental is only returned if the operator has made a
modification to the API behaviour that is non standard. This is only
intended to be a transitional mechanism while some functionality used
by cloud operators is upstreamed and it will be removed within a small
number of releases.
"

Thanks,
John