[openstack-dev] [sahara] [api] [sdks] [keystone] Sahara APIv2: service discovery

Jeremy Freudberg jeremyfreudberg at gmail.com
Thu Nov 30 21:07:45 UTC 2017

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.

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.

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

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.

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.


More information about the OpenStack-dev mailing list