I've been delayed in actually starting the grunt work on this. If anyone else besides Monty is also able to chime in, feel free.
I'm a bit lost in trying to find examples of clients doing version discovery + endpoint manipulation the "right way". If I could find a good example life would be easier. Stuff that constitutes the "right way": - use keystoneauth for version discovery (should we be using add_catalog_discover_hack [0] in Sahara's case?) - actually using keystoneauth discovery features when creating the client object (in my case, modifying [1]) - somehow putting the project id back in the URL (depending on at what point in the process this happens, can that just be "%(project_id)s" or must it be the actual project id, not sure) All help appreciated. Thanks! [0] https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/discover.py#L1224 [1] https://github.com/openstack/python-saharaclient/blob/master/saharaclient/api/client.py On Thu, Nov 30, 2017 at 7:34 PM, Monty Taylor <[email protected]> wrote: > > 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 > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
