Open Stack

On 03/27/2015 03:03 PM, Chris Friesen wrote:
> On 03/27/2015 12:44 PM, Dan Smith wrote:
>>> 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.
>>
>> Yes, but please note the last sentence in the quoted bit. This is to
>> help people clean their dirty laundry. Going forward, you shouldn't
>> expect to deliver features to your customers via this path.
>>
>>> That is *not* what I would call interoperability, this is exactly what
>>> we do not want.
>>
>> +1.
>
> So for the case where a customer really wants some functionality, and
> wants it *soon* rather than waiting for it to get merged upstream, what
> is the recommended implementation path for a vendor?

Get it merged upstream and then backported to stable branches. Yes, this 
takes time. Yes, it's a pain. Yes, it takes nagging sometimes. Yes, it 
annoys product managers.

> And what about stuff that's never going to get merged upstream because
> it's too specialized or too messy or depends on proprietary stuff?

See below.

> I ask this as an employee of a vendor that provides some modifications
> that customers seem to find useful (using the existing extensions
> mechanism to control them) and we want to do the right thing here.  Some
> of the modifications could make sense upstream and we are currently
> working on pushing those, but it's not at all clear how we're supposed
> to handle the above scenarios once the existing extension code gets
> removed.

Anything that affects the public compute API should be done from the 
start in the open in upstream.

True extensions or vendor add-ons should be done in an entirely separate 
REST API endpoint, IMO.

Best,
-jay