" 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
>
>

Reply via email to