" so the v3.0 codebase wouldn't share much if any code with the v2.0 codebase. "
Exactly - I would just use the v2.0 codebase as a model for writing the v3 codebase. "your question is about allowing the selection of v2 or v3 keystone to be configurable when a user is requesting compute, or having that choice be automatic based on URL regex or a response from a URL. Is that right?" Yes, that's exactly it. -----Original Message----- From: Alex Heneveld [mailto:alex.henev...@cloudsoftcorp.com] Sent: 21 May 2015 11:54 To: dev@jclouds.apache.org Subject: Re: Implementing OpenStack Identity v3 API Hi Darren, The Rackers or the Googlers can probably help more but to answer as best I can-- As you probably know the usual jclouds pattern is to treat different versions of an API as clean-room impls, so the v3.0 codebase wouldn't share much if any code with the v2.0 codebase. If a user wanted to access the v3 API in Java, they'd request it, differently to requesting the v2 API. Of course with openstack / nova / etc users don't request keystone, so your question is about allowing the selection of v2 or v3 keystone to be configurable when a user is requesting compute, or having that choice be automatic based on URL regex or a response from a URL. Is that right? Off the cuff my thinking is that you'd need an interface atop the v2 and the v3 API, so that nova etc don't need to be aware of which version is being used. (I'm not sure whether this exists?) Once you had that the obvious java answer is to have a new delegating impl for that interface, picking the underlying implementation, either v2 or v3, based on configuration and/or autodetection, and forwarding calls to that impl. And make that delegating impl be the impl used by nova etc. This isn't particularly Guice-y, however -- there is probably a Guice way to let the injection make the decision, instead of needing the delegate, but this is beyond my ken. Big caveat, I'm not an expert in either guice or the jclouds openstack impl -- hence the appeal to others -- but IHTH for starters. Best Alex On 21/05/2015 11:12, Hague, Darren wrote: > Hi all, > > Background: at SAP we would like to have OpenStack Identity V3 support in > jclouds (see https://issues.apache.org/jira/browse/JCLOUDS-114), and I am > working on implementing it. > I already implemented OpenStack Identity V3 support in Fog (Ruby's equivalent > to jclouds) - see > https://github.com/fog/fog/commit/803dedb297023a8ceee17d73e7c9e16764f3b34a > for details. > Using org.jclouds.keystone.v2_0 as a starting point, it's reasonably clear to > me how to go about implementing a v3 equivalent. > > My problem is this: I can't figure out how, in the jclouds codebase, to let > the user use v3 authentication instead of v2 authentication. > > Ideally I would like to get the same behaviour as Fog: when creating (for > example) a NovaApi object, the code would check to see if the endpoint URL > ends in "/v2.0" or "/v3" and use the v2.0 or v3 Identity implementation > accordingly. A workable (although suboptimal) alternative would be to let the > user somehow specify v3 as an override when creating a NovaApi object, e.g. > by passing in the v3 AuthenticationApiModule (which I already tried, but > doesn't work as-is). > > Can anybody help me with this? I'm happy to pair-program with a more > experience jclouds dev if that helps. > > Thanks in advance, > Darren > > Darren Hague > Cloud Lifecycle Management: Monsoon DevOps Team, > SAP (UK) Limited, Clockhouse Place, Bedfont Road, Feltham TW14 8HD, United > Kingdom > > T +44 208 917-8117, M +44 7764 97-8117, E d.ha...@sap.com > >