You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by "Hague, Darren" <d....@sap.com> on 2015/05/21 12:12:34 UTC
Implementing OpenStack Identity v3 API
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.hague@sap.com
Re: Implementing OpenStack Identity v3 API
Posted by Ignasi Barrera <na...@apache.org>.
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....@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.hague@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.heneveld@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.hague@sap.com
>>
>>
>
RE: Implementing OpenStack Identity v3 API
Posted by "Hague, Darren" <d....@sap.com>.
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.hague@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.heneveld@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.hague@sap.com
>
>
RE: Implementing OpenStack Identity v3 API
Posted by "Hague, Darren" <d....@sap.com>.
" 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.heneveld@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.hague@sap.com
>
>
Re: Implementing OpenStack Identity v3 API
Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
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.hague@sap.com
>
>