Open Stack

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
>>>> 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.

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.)

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 behaviour.

Chris