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 wrong) 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. Best, Jeremy __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev