[openstack-dev] [sahara] summit wrap-up: backward compat

Matthew Farrellee matt at redhat.com
Wed May 28 18:52:10 UTC 2014


On 05/28/2014 01:59 PM, Michael McCune wrote:
>
>
> ----- Original Message -----
>>> Open questions
>>
>> 1. How should we handle addition of new functionality to the API,
>> should we bump minor version and just add new endpoints?
>
> I think we should not include the minor revision number in the url.
> Looking at some of the other projects (nova, keystone) it looks like
> the preference to make the version endpoint able to return
> information about the specific version implemented. I think going
> forward, if we choose to bump the minor version for small features we
> can just change what the version endpoint returns. Any client would
> then be able to decide if they can use newer features based on the
> version reported from the return value. If we maintain a consistent
> version api endpoint then I don't see an issue with increasing the
> minor version based on new features being added. But, I only endorse
> this if we decide to solidify the version endpoint (e.g. /v2, not
> /v2.1).
>
> I realize this creates some confusion as we already have /v1 and
> /v1.1. I'm guessing we might subsume v1.1 at a point in time where we
> choose to deprecate.

i agree, no minor version number. we should even collapse v1.1 and v1 
for juno.

i don't think we need a capability discovery step. the api should 
already properly response w/ 404 for endpoints that do not exist.

the concern about only discovering a function isn't available until a 
few steps into a call sequence can be addressed with upfront endpoint 
detection. and i think this is an extremely rare corner case.


>> 2. For which period of time should we keep deprecated API and client for it?
>
> Not sure what the standard for OpenStack project is, but I would
> imagine we keep the deprecated API version for one release to give
> users time to migrate.

i'd say 1-2 cycles. pragmatically, we will probably never be able to 
remove api versions.


>> 3. How to publish all images and/or keep stability of building images
>> for plugins?
>
> This is a good question, I don't have a strong opinion at this time.
> My gut feeling is that we should maintain official images somewhere,
> but I realize this introduces more work in maintenance.

for each release we should distribute images for the non-deprecated 
plugin versions.

best,


matt



More information about the OpenStack-dev mailing list