Open Stack

On 12/01/2017 05:04 AM, Luigi Toscano wrote:
> On Friday, 1 December 2017 01:34:36 CET Monty Taylor wrote:
> 
>> First and most importantly you need to update python-saharaclient to
>> make sure it can handle it an unversioned endpoint in the catalog (by
>> doing discovery) - and that if it finds an unversioned endpoint in the
>> catalog it knows to prepend project-id to the urls is sends. The
>> easiest/best way to do this it to make sure it's delegating version
>> discovery to keystoneauth ... I will be more than happy to help you get
>> that updated.
>>
>> Then, for now, recommend that *new* deployments put the unversioned
>> endpoint into their catalog, but that existing deployments keep the v1
>> endpoint in the catalog even if they upgrade sahara to a version that
>> has v2 as well. (The full description of version discovery describes how
>> to get to a newer version even if an older version is in the catalog, so
>> people can opt-in to v2 if it's there with no trouble)
>>
>> That gets us to a state where:
>>
>> - existing deployments with users using v1 are not broken
>> - existing deployments that upgrade can have user's opt-in to v2 easily
>> - new deployments will have both v1 and v2 - but users who want to use
>> v1 will have to do so with a client that understands actually doing
>> discovery
> 
> Does it work even if we would like to keep v1 as default for a while? v2, at
> least in the first release, will be marked as experimental; hopefully it
> should stabilize soon, but still.

Totally. In the version discovery document returned by sahara, keep v1 
listed as "CURRENT" and list v2 as "EXPERIMENTAL". Then, when you're 
ready to declare v2 as the recommended API, change v1 to "SUPPORTED" and 
v1 to "CURRENT".