[openstack-dev] [nova] how to handle vendor-specific API microversions?
clint at fewbar.com
Wed Apr 1 00:03:38 UTC 2015
Excerpts from Lingxian Kong's message of 2015-03-23 21:11:28 -0700:
> 2015-03-21 23:31 GMT+08:00 Monty Taylor <mordred at inaugust.com>:
> > 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.
> But, what if some vendors have already implemented some on-premise
> features using the Nova extension mechanism, to achieve strategy of
> product differentiation themselves based on OpenStack? IMHO, the
> DefCore has already give some advise about what's OpenStack(you must
> pass through a lot of predefined tests). If vendors can not provide
> extra features by themselvs(which is backwards compatible), they will
> lose a little competitiveness on their product.
> I'm not very sure whether or not my understanding is right, but I
> really concern about the what's the right direction for the vendors or
What is being suggested is that those vendors need to write an API
that stands alone, apart from OpenStack's API's, with its own client
libraries and programs. This is to make it clear, those things are not
OpenStack. Extensions sort of hide in the shadows, and it is very hard
for a user to distinguish what they can depend on.
Think about the very nice alternatives that are GNU-specific for glibc.
If someone is writing an app that may need to land on many systems, they
must at least know to put those calls behind a layer of indirection that
they can focus on when porting. Same thing here.
Nobody wants to harm the ecosystem or discourage vendors from pushing into
corners where upstream might take too long to catch up. But OpenStack
isn't going to facilitate those things at the expense of the end-user
More information about the OpenStack-dev