Open Stack

On 11/30/2017 03:07 PM, Jeremy Freudberg wrote:
> Hi all,
> 
> In the Sahara world, we are getting ready to expose our experimental
> v2 API to real users and not just curious devs. Therefore we need to
> start thinking about service/version discovery of this new API.

\o/

> Earlier this year, the service types authority was created, and one of
> the things it asserted was that different service types for each API
> version (like Cinder and Mistral did) is bad.
> 
> So, it would entail that we should not adopt the `data-processingv2`
> service type.

Yes. Please don't... the service-types data has made its way into many 
places now.

> Unfortunately it's not so easy because Sahara API v1 relies on project
> ID in the URL, and therefore is expected to be registered with the
> project ID template in the Keystone service catalog. But API v2 does
> not accept project ID in the URL.
> 
> We don't want to break existing clients' ability to discover and use
> Sahara among all clouds. So if we changed the expectation of the
> endpoint for the current `dataprocessing` service type to never
> contain project ID, some clients might get spooked. (Correct me if I'm
> wrong)

WELL - there's totally a way to do this that works, although it's gonna 
be somewhat annoying.

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

Then let it sit that way for a while, and we can work to make sure that 
other clients with sahara support are also up to date with version 
discovery.

There will eventually come a point where a deployer will decide they 
want to change their catalog from /v1/{project_id} to / ... but by then 
we should have all the clients able to understand discovery fully.

> So, we either need to break the rules and create the
> `data-processingv2` type anyway, or we can create a new type just
> called, for example, `bigdata` which going forward can be used to
> discover either v1 or v2 without any interop concerns.

I think renaming to bigdata is less terrible than data-processing2 ... 
but let's see if we can't get things to work the other day first - 
there's a lot of churn otherwise.

> This is not an aspect of OpenStack I know a lot about, so any guidance
> is appreciated. Once we figure out a way forward I will make sure
> patches get proposed to the service types authority repo.

Almost nobody does. :) But we can totally figure this one out.

Monty