[openstack-dev] [nova] how to handle vendor-specific API microversions?
joe.gordon0 at gmail.com
Fri Mar 27 18:24:10 UTC 2015
On Fri, Mar 27, 2015 at 1:28 PM, Chris Friesen <chris.friesen at windriver.com>
> On 03/24/2015 11:10 AM, Chris Friesen wrote:
>> On 03/24/2015 07:42 AM, Sean Dague wrote:
>>> On 03/24/2015 09:11 AM, Jeremy Stanley wrote:
>>>> On 2015-03-23 22:34:17 -0600 (-0600), Chris Friesen wrote:
>>>>> How would that be expected to work for things where it's
>>>>> fundamentally just a minor extension to an existing nova API?
>>>>> (Exposing additional information as part of "nova show", for
>>>> Conversely, how do you recommend users of your environment reconcile
>>>> the difference in nova show output compared to what they get from
>>>> the other OpenStack environments they're using? How do you propose
>>>> to address the need for client libraries to cater to your divergent
>>>> API returning different numbers of parameters for certain methods?
>> We had been trying to control things properly via the extensions
>> mechanism so
>> that the changes could be documented/controlled.
>> As for clients, if the properties in the response are named, then simply
>> a new property to a response message body shouldn't be a problem--clients
>> just ignore properties that they don't understand.
>> I think these conversations work better in the concrete than the
>>> Chris, what additional attributes are you exposing on nova show which
>>> are critical for your installation? Can we figure out a way to
>>> generically support whatever that is?
>> In some cases it might be something that could conceivably go in
>> upstream, but
>> hasn't yet. This might be something as simple as having "nova show"
>> display the
>> server group that an instance is in, or it might be a bugfix that hasn't
>> merged upstream yet (like "https://review.openstack.org/#/c/16306" for
>> or it might be per-instance control over things that upstream currently
>> allows control over at the image/flavor level. Some of these might take a
>> release or two to get merged (and there's no guarantee that they would
>> ever be
>> merged) but customers want the functionality in the meantime.
>> In other cases the change is unlikely to ever be merged upstream, either
>> it's too domain-specific or the solution is messy or even proprietary.
> Haven't seen any responses to this.
> As I see it, nova is really pushing for interoperability, but what is a
> vendor supposed to do when they have customers asking for extensions to the
> existing behaviour, and they want it in a month rather than the 6-9 months
> it might take to push upstream? (Assuming its something that upstream is
> even interested in.)
To quote John from an earlier email in this thread:
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.
So if you have an extension that gets accepted upstream you can use the
experimental flag until you migrate to the upstream version of the
> I think it would be better to have an explicit method of
> declaring/versioning vendor-specific extensions (even if it's not used at
> all by the core Nova API) than to have each vendor winging it on their own.
> That way you would still get interoperability of the core Nova API
> (allowing customers to use multiple cloud vendors as long as they stick to
> the core API) while still giving a well-defined way to provide customized
That is *not* what I would call interoperability, this is exactly what we
do not want.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev