That sounds like a plan :) Once you get to step 3 (or before if you need), let's say hi in the #jclouds IRC channel at Freenode and I'll be happy (and I'm pretty sure others will) to help with that.
On 26 May 2015 at 12:43, Hague, Darren <d.ha...@sap.com> wrote: > OK, so here's how I plan to proceed: > > Step 1: Implement a standalone Identity V3 API under > jclouds/apis/openstack-keystone/src/main/java/org/jclouds/openstack/keystone/v3 > - to start with, just enough of the API to allow for authentication > > Step 2: Get the Nova API to work with the Keystone V3 API *instead of* the V2 > API - i.e. replace the hard-coded Keystone V2 references with hard-coded > Keystone V3 references. That scratches my team's itch of wanting to use > Keystone V3 for Nova authentication. > > Step 3: Figure out how to get the Nova API to choose Keystone V2 or Keystone > V3 based on the authentication endpoint URL used for initialization. This is > the hard part (for me, at least) - I'm having trouble penetrating all the > layers of indirection & dependency injection. I would really appreciate being > able to pair with someone when doing this step. > > Step 4: Implement the rest of the Identity V3 API. > > Does that sound OK to everyone? > > All the best, > Darren > > -----Original Message----- > From: Hague, Darren [mailto:d.ha...@sap.com] > Sent: 21 May 2015 13:03 > To: dev@jclouds.apache.org > Subject: RE: Implementing OpenStack Identity v3 API > > " 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 >> >> >
