Open Stack

On Fri, Mar 27, 2015 at 1:28 PM, Chris Friesen <chris.friesen at windriver.com>
wrote:

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


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


That is *not* what I would call interoperability, this is exactly what we
do not want.


>
>
> Chris
>
> __________________________________________________________________________
> 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/20150327/71f4532f/attachment.html>