[openstack-dev] [Glance] Experimental API

McLellan, Steven steve.mclellan at hp.com
Thu Mar 12 19:48:51 UTC 2015

This would require some changes to how python-glanceclient parses
versions. Even if the keystone catalog has a version string in it (which
typically is not the case for glance) the version parsing in common/utils
only recognizes version strings beginning with 'v'.

Would it be sensible to add clients/x1 (that might largely inherit from
clients/v2 code)? Or alter glanceclient/client to treat an 'x' version as
the same as 'v' (in which case maybe 'use /x2')?


On 3/12/15, 1:42 PM, "Brian Rosmaita" <brian.rosmaita at RACKSPACE.COM> wrote:

>I don't know how elaborate we want to get here, but Everett Toews had an
>interesting suggestion in the openstack-api channel. It would go something
>like this: 
>(1) User gets "/x1/search" endpoint from service catalog
>(2) User does some request against /x1/search
>(3) User receives 400 with an error message like:
>This is an experimental API.
>You must include the following header with your request:
>    x-openstack-api-status: acknowledged
>By using this header, you acknowledge that while we think this API is
>pretty solid, we reserve the right to make breaking changes as we analyze
>usage patterns and API consumer comments during the experimental period.
>Please send comments to the OpenStack Future Development Mailing List with
>the subject "[Glance] x1 API".
>To subscribe to the mailing list:
>(4) User makes all subsequent requests including the
>x-openstack-api-status header
>If we did something like that, my conscience would be completely clean if
>we wound up introducing a breaking change.
>On 3/12/15, 1:19 PM, "Sampath, Lakshmi" <lakshmi.sampath at hp.com> wrote:
>>We had a discussion with API WG today about what it means to be an
>>"EXPERIMENTAL API" and here's the takeway from that discussion.
>>- API's can be experimental, but mark it clearly in the docs as such
>>- Experimental means a breaking change may be introduced
>>- Use /x1/ instead of /v1/  in the endpoint.
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe

More information about the OpenStack-dev mailing list