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

This is why Red Hat's development approach is "upstream first".  You
really screw yourself if you ship something before it goes upstream,
*especially* when the changes are user visible.

I'm really not interested in the "never going upstream" case at all.
It's damaging to users and the OpenStack ecosystem overall.  That view
seems pretty widely shared in this thread so far.

However, I think the question of backporting a feature that has landed
upstream that Steve Gordon just raised is a good case to consider.

-- 
Russell Bryant