Open Stack

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*

>
>
> __________________________________________________________________________
> 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/20150321/a0b6a4b2/attachment.html>