[openstack-dev] [nova] how to handle vendor-specific API microversions?
Chris Friesen
chris.friesen at windriver.com
Tue Mar 24 17:10:47 UTC 2015
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
>>> example.)
>>
>> 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 adding
a new property to a response message body shouldn't be a problem--clients could
just ignore properties that they don't understand.
> I think these conversations work better in the concrete than the abstract.
>
> 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 been
merged upstream yet (like "https://review.openstack.org/#/c/16306" for example)
or it might be per-instance control over things that upstream currently only
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 because
it's too domain-specific or the solution is messy or even proprietary.
Chris
More information about the OpenStack-dev
mailing list