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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
