You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Etienne Carriere <et...@gmail.com> on 2016/12/28 15:36:46 UTC
Managing non-openstack swift in jclouds
Hi,
In our project, we currently need to interact with differents types of
swift implementations :
- Ceph with radosgw
- NetApp appliance with swift endpoint
Thoses implementions use "identity v1 protocol" which is an old but simple
API for the authentication and don't use identity v2 protocol (
http://developer.openstack.org/api-ref/identity/v2/index.html) which is
implemented by jclouds in openstack-keystone module .
*State of jclouds*
The openstack swift "official" client (in python) manage this v1 protocol (
http://docs.openstack.org/developer/python-swiftclient/swiftclient.html) so
even if we don't have a specification, we will use the code of the official
client for the implementation.
In jclouds, there is currently a sort-of v1 identity protocol in the
openstack-swift module: in
apis/openstack-swift/src/main/java/org/jclouds/openstack/swift/v1/config/SwiftAuthenticationModule.java,
there is a tempAuthCredentials which is almost the identity v1 protocol
except that the name of the headers was not the same :
= X-Storage-User vs X-Auth-User
= X-Storage-Path vs X-Auth-Key
*Proposal*
In our project, we think about the following solution
= Keep the current behaviour as default
= Add 2 parameters to change the header name through variables in the
Properties put in the Builder like that :
Properties overrides = new Properties();
overrides.setProperty("jclouds.keystone.credential-type",
"tempAuthCredentials");
overrides.setProperty("jclouds.swift.tempAuth.headerUser",
"X-Auth-User");
overrides.setProperty("jclouds.swift.tempAuth.headerPass",
"X-Auth-Pass");
swiftApi = ContextBuilder.newBuilder(provider)
.endpoint(args[1])
.credentials(identity, credential)
.modules(modules)
.overrides(overrides)
.buildApi(SwiftApi.class);
*Questions*
1) Will this behaviour acceptable upstream ? (and what is the lifecycle
planned for this tempAuthCredentials)
2) As working on the patch, we have issues to use the variables injected by
the overrides method. After analysing some parts of the code of
openstack-keystone module, i tried to use @Named and @Inject but without
success. Is there some doc or some hints on how to do that ?
Thanks in advance,
Regards,
Etienne Carrière
Re: Managing non-openstack swift in jclouds
Posted by Ignasi Barrera <na...@apache.org>.
Yes, it should. Let's continue discussing the implementation details
in the pull request. Thanks for submitting the patch!
On 3 January 2017 at 18:26, Etienne Carriere <et...@gmail.com> wrote:
> Hi Ignasi,
>
> I just read your mail after having done the Bug in JIRA (#1220) and the PR
> on github (#1046). I managed to "have something working" by adding a
> requestStaticInjection but I understand it is not the "standard method" for
> Jclouds.
> If I move to the binder class, do the injection will be "automatic" or
> something has to be declared ?
>
> Thanks in advance,
>
> Regards,
>
> Etienne Carrière
>
> 2017-01-03 16:11 GMT+01:00 Ignasi Barrera <na...@apache.org>:
>
>> Hi Etienne,
>>
>> Apologies for the late reply. I've had a look at your patch and I like
>> proposed the solution.
>>
>> I think the problem in your code is that you are configuring the
>> injection in the Guice module itself. Guice modules are used to
>> configure "what and how" is injected, but they should not contain
>> injected variables or constructors, since one manually instantiates
>> them (when passing it to the context builder) instead of requesting an
>> instance to the Guice injector.
>>
>> Making it work would be simple: just move all the header constants and
>> variables to your Binder class and let injection happen there. It also
>> makes more sense, since that's the place where the headers are needed.
>>
>> Let us know if that works, and look forward to seeing a PR for this! :)
>>
>>
>> HTH!
>>
>> I.
>>
>> On 30 December 2016 at 17:59, Etienne Carriere
>> <et...@gmail.com> wrote:
>> > Hi Andrea,
>> >
>> > Thank you for your answer.
>> > Concerning the 2 points :
>> > * my current patch is available here :
>> > https://github.com/Etienne-Carriere/jclouds/commit/
>> fd9057573935b6f95e8cab6526790e0b79a5e843#diff-
>> 4f8d0e6c4a8bc4add7203bcbfe4bbf6eR71
>> > * I take the example on the BaseAuthenticator class (
>> > https://github.com/jclouds/jclouds/blob/4bbca9edf943852ce1ea5aa579fa05
>> 54f770a3ea/apis/openstack-keystone/src/main/java/org/
>> jclouds/openstack/keystone/v2_0/functions/internal/
>> BaseAuthenticator.java#L45)
>> > for the injection of the property given through overrides method of the
>> > builder.
>> >
>> > Unfortunately it doesn't work . The value of the variable is null even
>> if I
>> > push the property.
>> >
>> > Regards,
>> >
>> > Etienne Carrière
>> >
>> >
>> >
>> >
>> > 2016-12-30 16:58 GMT+01:00 Andrea Turli <an...@gmail.com>:
>> >
>> >> Hi Etienne,
>> >>
>> >> sorry for the late answer.
>> >>
>> >> Unfortunately I'm not really familiar with this details of swift but I
>> >> think what you are proposing makes sense to me.
>> >>
>> >> I'd suggest to fist send a working example, maybe updating
>> >> https://github.com/jclouds/jclouds-examples/tree/master/
>> blobstore-basics
>> >> but not sure, and potentially re-start there the conversation around the
>> >> question #1
>> >>
>> >> Re #2, can you elaborate a bit more when you say "we have issues to use
>> the
>> >> variables injected by the overrides method" what are you trying to
>> achieve?
>> >>
>> >> HTH,
>> >> Andrea
>> >>
>> >> On Wed, Dec 28, 2016 at 4:36 PM, Etienne Carriere <
>> >> etienne.carriere@gmail.com> wrote:
>> >>
>> >> > Hi,
>> >> >
>> >> > In our project, we currently need to interact with differents types of
>> >> > swift implementations :
>> >> > - Ceph with radosgw
>> >> > - NetApp appliance with swift endpoint
>> >> >
>> >> > Thoses implementions use "identity v1 protocol" which is an old but
>> >> simple
>> >> > API for the authentication and don't use identity v2 protocol (
>> >> > http://developer.openstack.org/api-ref/identity/v2/index.html) which
>> is
>> >> > implemented by jclouds in openstack-keystone module .
>> >> >
>> >> >
>> >> > *State of jclouds*
>> >> > The openstack swift "official" client (in python) manage this v1
>> >> protocol (
>> >> > http://docs.openstack.org/developer/python-swiftclient/
>> swiftclient.html)
>> >> > so
>> >> > even if we don't have a specification, we will use the code of the
>> >> official
>> >> > client for the implementation.
>> >> >
>> >> > In jclouds, there is currently a sort-of v1 identity protocol in the
>> >> > openstack-swift module: in
>> >> > apis/openstack-swift/src/main/java/org/jclouds/openstack/
>> >> swift/v1/config/
>> >> > SwiftAuthenticationModule.java,
>> >> > there is a tempAuthCredentials which is almost the identity v1
>> protocol
>> >> > except that the name of the headers was not the same :
>> >> > = X-Storage-User vs X-Auth-User
>> >> > = X-Storage-Path vs X-Auth-Key
>> >> >
>> >> > *Proposal*
>> >> > In our project, we think about the following solution
>> >> > = Keep the current behaviour as default
>> >> > = Add 2 parameters to change the header name through variables in
>> the
>> >> > Properties put in the Builder like that :
>> >> >
>> >> > Properties overrides = new Properties();
>> >> > overrides.setProperty("jclouds.keystone.credential-type",
>> >> > "tempAuthCredentials");
>> >> > overrides.setProperty("jclouds.swift.tempAuth.headerUser",
>> >> > "X-Auth-User");
>> >> > overrides.setProperty("jclouds.swift.tempAuth.headerPass",
>> >> > "X-Auth-Pass");
>> >> > swiftApi = ContextBuilder.newBuilder(provider)
>> >> > .endpoint(args[1])
>> >> > .credentials(identity, credential)
>> >> > .modules(modules)
>> >> > .overrides(overrides)
>> >> > .buildApi(SwiftApi.class);
>> >> >
>> >> > *Questions*
>> >> > 1) Will this behaviour acceptable upstream ? (and what is the
>> lifecycle
>> >> > planned for this tempAuthCredentials)
>> >> > 2) As working on the patch, we have issues to use the variables
>> injected
>> >> by
>> >> > the overrides method. After analysing some parts of the code of
>> >> > openstack-keystone module, i tried to use @Named and @Inject but
>> without
>> >> > success. Is there some doc or some hints on how to do that ?
>> >> >
>> >> > Thanks in advance,
>> >> >
>> >> > Regards,
>> >> >
>> >> > Etienne Carrière
>> >> >
>> >>
>>
Re: Managing non-openstack swift in jclouds
Posted by Etienne Carriere <et...@gmail.com>.
Hi Ignasi,
I just read your mail after having done the Bug in JIRA (#1220) and the PR
on github (#1046). I managed to "have something working" by adding a
requestStaticInjection but I understand it is not the "standard method" for
Jclouds.
If I move to the binder class, do the injection will be "automatic" or
something has to be declared ?
Thanks in advance,
Regards,
Etienne Carrière
2017-01-03 16:11 GMT+01:00 Ignasi Barrera <na...@apache.org>:
> Hi Etienne,
>
> Apologies for the late reply. I've had a look at your patch and I like
> proposed the solution.
>
> I think the problem in your code is that you are configuring the
> injection in the Guice module itself. Guice modules are used to
> configure "what and how" is injected, but they should not contain
> injected variables or constructors, since one manually instantiates
> them (when passing it to the context builder) instead of requesting an
> instance to the Guice injector.
>
> Making it work would be simple: just move all the header constants and
> variables to your Binder class and let injection happen there. It also
> makes more sense, since that's the place where the headers are needed.
>
> Let us know if that works, and look forward to seeing a PR for this! :)
>
>
> HTH!
>
> I.
>
> On 30 December 2016 at 17:59, Etienne Carriere
> <et...@gmail.com> wrote:
> > Hi Andrea,
> >
> > Thank you for your answer.
> > Concerning the 2 points :
> > * my current patch is available here :
> > https://github.com/Etienne-Carriere/jclouds/commit/
> fd9057573935b6f95e8cab6526790e0b79a5e843#diff-
> 4f8d0e6c4a8bc4add7203bcbfe4bbf6eR71
> > * I take the example on the BaseAuthenticator class (
> > https://github.com/jclouds/jclouds/blob/4bbca9edf943852ce1ea5aa579fa05
> 54f770a3ea/apis/openstack-keystone/src/main/java/org/
> jclouds/openstack/keystone/v2_0/functions/internal/
> BaseAuthenticator.java#L45)
> > for the injection of the property given through overrides method of the
> > builder.
> >
> > Unfortunately it doesn't work . The value of the variable is null even
> if I
> > push the property.
> >
> > Regards,
> >
> > Etienne Carrière
> >
> >
> >
> >
> > 2016-12-30 16:58 GMT+01:00 Andrea Turli <an...@gmail.com>:
> >
> >> Hi Etienne,
> >>
> >> sorry for the late answer.
> >>
> >> Unfortunately I'm not really familiar with this details of swift but I
> >> think what you are proposing makes sense to me.
> >>
> >> I'd suggest to fist send a working example, maybe updating
> >> https://github.com/jclouds/jclouds-examples/tree/master/
> blobstore-basics
> >> but not sure, and potentially re-start there the conversation around the
> >> question #1
> >>
> >> Re #2, can you elaborate a bit more when you say "we have issues to use
> the
> >> variables injected by the overrides method" what are you trying to
> achieve?
> >>
> >> HTH,
> >> Andrea
> >>
> >> On Wed, Dec 28, 2016 at 4:36 PM, Etienne Carriere <
> >> etienne.carriere@gmail.com> wrote:
> >>
> >> > Hi,
> >> >
> >> > In our project, we currently need to interact with differents types of
> >> > swift implementations :
> >> > - Ceph with radosgw
> >> > - NetApp appliance with swift endpoint
> >> >
> >> > Thoses implementions use "identity v1 protocol" which is an old but
> >> simple
> >> > API for the authentication and don't use identity v2 protocol (
> >> > http://developer.openstack.org/api-ref/identity/v2/index.html) which
> is
> >> > implemented by jclouds in openstack-keystone module .
> >> >
> >> >
> >> > *State of jclouds*
> >> > The openstack swift "official" client (in python) manage this v1
> >> protocol (
> >> > http://docs.openstack.org/developer/python-swiftclient/
> swiftclient.html)
> >> > so
> >> > even if we don't have a specification, we will use the code of the
> >> official
> >> > client for the implementation.
> >> >
> >> > In jclouds, there is currently a sort-of v1 identity protocol in the
> >> > openstack-swift module: in
> >> > apis/openstack-swift/src/main/java/org/jclouds/openstack/
> >> swift/v1/config/
> >> > SwiftAuthenticationModule.java,
> >> > there is a tempAuthCredentials which is almost the identity v1
> protocol
> >> > except that the name of the headers was not the same :
> >> > = X-Storage-User vs X-Auth-User
> >> > = X-Storage-Path vs X-Auth-Key
> >> >
> >> > *Proposal*
> >> > In our project, we think about the following solution
> >> > = Keep the current behaviour as default
> >> > = Add 2 parameters to change the header name through variables in
> the
> >> > Properties put in the Builder like that :
> >> >
> >> > Properties overrides = new Properties();
> >> > overrides.setProperty("jclouds.keystone.credential-type",
> >> > "tempAuthCredentials");
> >> > overrides.setProperty("jclouds.swift.tempAuth.headerUser",
> >> > "X-Auth-User");
> >> > overrides.setProperty("jclouds.swift.tempAuth.headerPass",
> >> > "X-Auth-Pass");
> >> > swiftApi = ContextBuilder.newBuilder(provider)
> >> > .endpoint(args[1])
> >> > .credentials(identity, credential)
> >> > .modules(modules)
> >> > .overrides(overrides)
> >> > .buildApi(SwiftApi.class);
> >> >
> >> > *Questions*
> >> > 1) Will this behaviour acceptable upstream ? (and what is the
> lifecycle
> >> > planned for this tempAuthCredentials)
> >> > 2) As working on the patch, we have issues to use the variables
> injected
> >> by
> >> > the overrides method. After analysing some parts of the code of
> >> > openstack-keystone module, i tried to use @Named and @Inject but
> without
> >> > success. Is there some doc or some hints on how to do that ?
> >> >
> >> > Thanks in advance,
> >> >
> >> > Regards,
> >> >
> >> > Etienne Carrière
> >> >
> >>
>
Re: Managing non-openstack swift in jclouds
Posted by Ignasi Barrera <na...@apache.org>.
Hi Etienne,
Apologies for the late reply. I've had a look at your patch and I like
proposed the solution.
I think the problem in your code is that you are configuring the
injection in the Guice module itself. Guice modules are used to
configure "what and how" is injected, but they should not contain
injected variables or constructors, since one manually instantiates
them (when passing it to the context builder) instead of requesting an
instance to the Guice injector.
Making it work would be simple: just move all the header constants and
variables to your Binder class and let injection happen there. It also
makes more sense, since that's the place where the headers are needed.
Let us know if that works, and look forward to seeing a PR for this! :)
HTH!
I.
On 30 December 2016 at 17:59, Etienne Carriere
<et...@gmail.com> wrote:
> Hi Andrea,
>
> Thank you for your answer.
> Concerning the 2 points :
> * my current patch is available here :
> https://github.com/Etienne-Carriere/jclouds/commit/fd9057573935b6f95e8cab6526790e0b79a5e843#diff-4f8d0e6c4a8bc4add7203bcbfe4bbf6eR71
> * I take the example on the BaseAuthenticator class (
> https://github.com/jclouds/jclouds/blob/4bbca9edf943852ce1ea5aa579fa0554f770a3ea/apis/openstack-keystone/src/main/java/org/jclouds/openstack/keystone/v2_0/functions/internal/BaseAuthenticator.java#L45)
> for the injection of the property given through overrides method of the
> builder.
>
> Unfortunately it doesn't work . The value of the variable is null even if I
> push the property.
>
> Regards,
>
> Etienne Carrière
>
>
>
>
> 2016-12-30 16:58 GMT+01:00 Andrea Turli <an...@gmail.com>:
>
>> Hi Etienne,
>>
>> sorry for the late answer.
>>
>> Unfortunately I'm not really familiar with this details of swift but I
>> think what you are proposing makes sense to me.
>>
>> I'd suggest to fist send a working example, maybe updating
>> https://github.com/jclouds/jclouds-examples/tree/master/blobstore-basics
>> but not sure, and potentially re-start there the conversation around the
>> question #1
>>
>> Re #2, can you elaborate a bit more when you say "we have issues to use the
>> variables injected by the overrides method" what are you trying to achieve?
>>
>> HTH,
>> Andrea
>>
>> On Wed, Dec 28, 2016 at 4:36 PM, Etienne Carriere <
>> etienne.carriere@gmail.com> wrote:
>>
>> > Hi,
>> >
>> > In our project, we currently need to interact with differents types of
>> > swift implementations :
>> > - Ceph with radosgw
>> > - NetApp appliance with swift endpoint
>> >
>> > Thoses implementions use "identity v1 protocol" which is an old but
>> simple
>> > API for the authentication and don't use identity v2 protocol (
>> > http://developer.openstack.org/api-ref/identity/v2/index.html) which is
>> > implemented by jclouds in openstack-keystone module .
>> >
>> >
>> > *State of jclouds*
>> > The openstack swift "official" client (in python) manage this v1
>> protocol (
>> > http://docs.openstack.org/developer/python-swiftclient/swiftclient.html)
>> > so
>> > even if we don't have a specification, we will use the code of the
>> official
>> > client for the implementation.
>> >
>> > In jclouds, there is currently a sort-of v1 identity protocol in the
>> > openstack-swift module: in
>> > apis/openstack-swift/src/main/java/org/jclouds/openstack/
>> swift/v1/config/
>> > SwiftAuthenticationModule.java,
>> > there is a tempAuthCredentials which is almost the identity v1 protocol
>> > except that the name of the headers was not the same :
>> > = X-Storage-User vs X-Auth-User
>> > = X-Storage-Path vs X-Auth-Key
>> >
>> > *Proposal*
>> > In our project, we think about the following solution
>> > = Keep the current behaviour as default
>> > = Add 2 parameters to change the header name through variables in the
>> > Properties put in the Builder like that :
>> >
>> > Properties overrides = new Properties();
>> > overrides.setProperty("jclouds.keystone.credential-type",
>> > "tempAuthCredentials");
>> > overrides.setProperty("jclouds.swift.tempAuth.headerUser",
>> > "X-Auth-User");
>> > overrides.setProperty("jclouds.swift.tempAuth.headerPass",
>> > "X-Auth-Pass");
>> > swiftApi = ContextBuilder.newBuilder(provider)
>> > .endpoint(args[1])
>> > .credentials(identity, credential)
>> > .modules(modules)
>> > .overrides(overrides)
>> > .buildApi(SwiftApi.class);
>> >
>> > *Questions*
>> > 1) Will this behaviour acceptable upstream ? (and what is the lifecycle
>> > planned for this tempAuthCredentials)
>> > 2) As working on the patch, we have issues to use the variables injected
>> by
>> > the overrides method. After analysing some parts of the code of
>> > openstack-keystone module, i tried to use @Named and @Inject but without
>> > success. Is there some doc or some hints on how to do that ?
>> >
>> > Thanks in advance,
>> >
>> > Regards,
>> >
>> > Etienne Carrière
>> >
>>
Re: Managing non-openstack swift in jclouds
Posted by Etienne Carriere <et...@gmail.com>.
Hi Andrea,
Thank you for your answer.
Concerning the 2 points :
* my current patch is available here :
https://github.com/Etienne-Carriere/jclouds/commit/fd9057573935b6f95e8cab6526790e0b79a5e843#diff-4f8d0e6c4a8bc4add7203bcbfe4bbf6eR71
* I take the example on the BaseAuthenticator class (
https://github.com/jclouds/jclouds/blob/4bbca9edf943852ce1ea5aa579fa0554f770a3ea/apis/openstack-keystone/src/main/java/org/jclouds/openstack/keystone/v2_0/functions/internal/BaseAuthenticator.java#L45)
for the injection of the property given through overrides method of the
builder.
Unfortunately it doesn't work . The value of the variable is null even if I
push the property.
Regards,
Etienne Carrière
2016-12-30 16:58 GMT+01:00 Andrea Turli <an...@gmail.com>:
> Hi Etienne,
>
> sorry for the late answer.
>
> Unfortunately I'm not really familiar with this details of swift but I
> think what you are proposing makes sense to me.
>
> I'd suggest to fist send a working example, maybe updating
> https://github.com/jclouds/jclouds-examples/tree/master/blobstore-basics
> but not sure, and potentially re-start there the conversation around the
> question #1
>
> Re #2, can you elaborate a bit more when you say "we have issues to use the
> variables injected by the overrides method" what are you trying to achieve?
>
> HTH,
> Andrea
>
> On Wed, Dec 28, 2016 at 4:36 PM, Etienne Carriere <
> etienne.carriere@gmail.com> wrote:
>
> > Hi,
> >
> > In our project, we currently need to interact with differents types of
> > swift implementations :
> > - Ceph with radosgw
> > - NetApp appliance with swift endpoint
> >
> > Thoses implementions use "identity v1 protocol" which is an old but
> simple
> > API for the authentication and don't use identity v2 protocol (
> > http://developer.openstack.org/api-ref/identity/v2/index.html) which is
> > implemented by jclouds in openstack-keystone module .
> >
> >
> > *State of jclouds*
> > The openstack swift "official" client (in python) manage this v1
> protocol (
> > http://docs.openstack.org/developer/python-swiftclient/swiftclient.html)
> > so
> > even if we don't have a specification, we will use the code of the
> official
> > client for the implementation.
> >
> > In jclouds, there is currently a sort-of v1 identity protocol in the
> > openstack-swift module: in
> > apis/openstack-swift/src/main/java/org/jclouds/openstack/
> swift/v1/config/
> > SwiftAuthenticationModule.java,
> > there is a tempAuthCredentials which is almost the identity v1 protocol
> > except that the name of the headers was not the same :
> > = X-Storage-User vs X-Auth-User
> > = X-Storage-Path vs X-Auth-Key
> >
> > *Proposal*
> > In our project, we think about the following solution
> > = Keep the current behaviour as default
> > = Add 2 parameters to change the header name through variables in the
> > Properties put in the Builder like that :
> >
> > Properties overrides = new Properties();
> > overrides.setProperty("jclouds.keystone.credential-type",
> > "tempAuthCredentials");
> > overrides.setProperty("jclouds.swift.tempAuth.headerUser",
> > "X-Auth-User");
> > overrides.setProperty("jclouds.swift.tempAuth.headerPass",
> > "X-Auth-Pass");
> > swiftApi = ContextBuilder.newBuilder(provider)
> > .endpoint(args[1])
> > .credentials(identity, credential)
> > .modules(modules)
> > .overrides(overrides)
> > .buildApi(SwiftApi.class);
> >
> > *Questions*
> > 1) Will this behaviour acceptable upstream ? (and what is the lifecycle
> > planned for this tempAuthCredentials)
> > 2) As working on the patch, we have issues to use the variables injected
> by
> > the overrides method. After analysing some parts of the code of
> > openstack-keystone module, i tried to use @Named and @Inject but without
> > success. Is there some doc or some hints on how to do that ?
> >
> > Thanks in advance,
> >
> > Regards,
> >
> > Etienne Carrière
> >
>
Re: Managing non-openstack swift in jclouds
Posted by Andrea Turli <an...@gmail.com>.
Hi Etienne,
sorry for the late answer.
Unfortunately I'm not really familiar with this details of swift but I
think what you are proposing makes sense to me.
I'd suggest to fist send a working example, maybe updating
https://github.com/jclouds/jclouds-examples/tree/master/blobstore-basics
but not sure, and potentially re-start there the conversation around the
question #1
Re #2, can you elaborate a bit more when you say "we have issues to use the
variables injected by the overrides method" what are you trying to achieve?
HTH,
Andrea
On Wed, Dec 28, 2016 at 4:36 PM, Etienne Carriere <
etienne.carriere@gmail.com> wrote:
> Hi,
>
> In our project, we currently need to interact with differents types of
> swift implementations :
> - Ceph with radosgw
> - NetApp appliance with swift endpoint
>
> Thoses implementions use "identity v1 protocol" which is an old but simple
> API for the authentication and don't use identity v2 protocol (
> http://developer.openstack.org/api-ref/identity/v2/index.html) which is
> implemented by jclouds in openstack-keystone module .
>
>
> *State of jclouds*
> The openstack swift "official" client (in python) manage this v1 protocol (
> http://docs.openstack.org/developer/python-swiftclient/swiftclient.html)
> so
> even if we don't have a specification, we will use the code of the official
> client for the implementation.
>
> In jclouds, there is currently a sort-of v1 identity protocol in the
> openstack-swift module: in
> apis/openstack-swift/src/main/java/org/jclouds/openstack/swift/v1/config/
> SwiftAuthenticationModule.java,
> there is a tempAuthCredentials which is almost the identity v1 protocol
> except that the name of the headers was not the same :
> = X-Storage-User vs X-Auth-User
> = X-Storage-Path vs X-Auth-Key
>
> *Proposal*
> In our project, we think about the following solution
> = Keep the current behaviour as default
> = Add 2 parameters to change the header name through variables in the
> Properties put in the Builder like that :
>
> Properties overrides = new Properties();
> overrides.setProperty("jclouds.keystone.credential-type",
> "tempAuthCredentials");
> overrides.setProperty("jclouds.swift.tempAuth.headerUser",
> "X-Auth-User");
> overrides.setProperty("jclouds.swift.tempAuth.headerPass",
> "X-Auth-Pass");
> swiftApi = ContextBuilder.newBuilder(provider)
> .endpoint(args[1])
> .credentials(identity, credential)
> .modules(modules)
> .overrides(overrides)
> .buildApi(SwiftApi.class);
>
> *Questions*
> 1) Will this behaviour acceptable upstream ? (and what is the lifecycle
> planned for this tempAuthCredentials)
> 2) As working on the patch, we have issues to use the variables injected by
> the overrides method. After analysing some parts of the code of
> openstack-keystone module, i tried to use @Named and @Inject but without
> success. Is there some doc or some hints on how to do that ?
>
> Thanks in advance,
>
> Regards,
>
> Etienne Carrière
>