You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by "Andrea Turli (apache.org)" <an...@apache.org> on 2017/11/20 16:55:53 UTC
Openstack Keystone v3 finally!
Hi team,
happy to say I've finally had some time to properly look at
https://issues.apache.org/jira/browse/JCLOUDS-114
At the moment it still lives in my own development branch but the idea here
is to add a Guice module for each Openstack service version jclouds
supports, i.e. KeystoneV2 and KeystoneV3
I think we should break the hard-coded link with KeystoneV2 from Nova and
the other downstream Openstack services that require Keystone. In this way,
the apis/openstack-* will be really generic and independent, and the
providers/a-openstack-based-provider will compose the Guice modules
according to the specific requirements.
Here an example:
public static class Builder extends BaseProviderMetadata.Builder {
protected Builder() {
id("x")
.name("X")
.apiMetadata(new NovaApiMetadata().toBuilder()
.identityName("${userName}")
.credentialName("${apiKey}")
.version("3")
.defaultEndpoint("https://identity.x.com/v3")
.endpointName("identity service url ending in /v3")
.documentation(URI.create("https://x.doc.html"))
.defaultModules(ImmutableSet.<Class<? extends
Module>>builder()
.add(KeystoneV3Module.class)
.add(NovaParserModule.class)
.build())
.build())
Notice thanks to
https://github.com/jclouds/jclouds/pull/960#issuecomment-221209582 we can
go even a bit further and link the Neutron context from Nova context.
This means, for example, that Nova code should try to use Neutron (modern
way to deal with network concepts in Openstack) but fallback to Nova
security groups, if Neutron is not linked.
----
This work requires to touch quite a lot of repos so I may need multiple PRs
but at least we have a proposal to add KeystoneV3 support.
----
I also think multiple Guice modules can be a good pattern to support
multiple version of the same API, in general, not only for Openstack.
----
Thanks @nacx and Richard Downer from Apache Brooklyn for the great help!
Re: Openstack Keystone v3 finally!
Posted by Ignasi Barrera <na...@apache.org>.
Hi all!
OpenStack Keystone V3 support has been finally merged in the main
branch and will be released in short as part of the 2.1.0 release.
You can read the blog post with the upgrade notes and other details here:
https://jclouds.apache.org/blog/2018/01/16/keystone-v3/
Cheers!
I.
On 15 January 2018 at 16:49, Ignasi Barrera <na...@apache.org> wrote:
> Here it is! Finally! :D
> https://github.com/jclouds/jclouds/pull/1170
>
> On 12 January 2018 at 00:31, Andrew Phillips <ap...@qrmedia.com> wrote:
>>> A quick update on this: we're running the final tests before opening
>>> the pull request.
>>
>>
>> Yeeeeeeeeehaaaaaaaa!!
>>
>> ap
Re: Openstack Keystone v3 finally!
Posted by Ignasi Barrera <na...@apache.org>.
Here it is! Finally! :D
https://github.com/jclouds/jclouds/pull/1170
On 12 January 2018 at 00:31, Andrew Phillips <ap...@qrmedia.com> wrote:
>> A quick update on this: we're running the final tests before opening
>> the pull request.
>
>
> Yeeeeeeeeehaaaaaaaa!!
>
> ap
Re: Openstack Keystone v3 finally!
Posted by Andrew Phillips <ap...@qrmedia.com>.
> A quick update on this: we're running the final tests before opening
> the pull request.
Yeeeeeeeeehaaaaaaaa!!
ap
Re: Openstack Keystone v3 finally!
Posted by Ignasi Barrera <na...@apache.org>.
A quick update on this: we're running the final tests before opening
the pull request. The branch should be fully functional now and I
encourage anyone interested in it to check it out and play a bit.
You will find some instructions in the WIP for the blog post we'll
publish when announcing the feature:
https://github.com/jclouds/jclouds-site/pull/206
On 8 December 2017 at 14:04, Ignasi Barrera <na...@apache.org> wrote:
> For those interested in this, we have now a live branch in the repo.
> It supports authentication with Keystone V2 and Keystone V3 and in the
> following days we'll be doing some tests on several providers and
> environments.
>
> Stay tuned to this list, the "keystonev3" branch [1], and the IRC [2]
> and slack [3] channel logs for the most up to date status of this!
>
> I.
>
> [1] https://github.com/jclouds/jclouds/tree/keystonev3
> [2] https://botbot.me/freenode/jclouds/
> [3] https://the-asf.slackarchive.io/jclouds
>
> On 20 November 2017 at 21:09, Ignasi Barrera <na...@apache.org> wrote:
>> Huge effort Andrea!!!
>>
>> Look forward to having a look and early-testing it!
>>
>> On Nov 20, 2017 5:56 PM, "Andrea Turli (apache.org)"
>> <an...@apache.org> wrote:
>>>
>>> Hi team,
>>>
>>> happy to say I've finally had some time to properly look at
>>> https://issues.apache.org/jira/browse/JCLOUDS-114
>>>
>>> At the moment it still lives in my own development branch but the idea
>>> here
>>> is to add a Guice module for each Openstack service version jclouds
>>> supports, i.e. KeystoneV2 and KeystoneV3
>>>
>>> I think we should break the hard-coded link with KeystoneV2 from Nova and
>>> the other downstream Openstack services that require Keystone. In this
>>> way,
>>> the apis/openstack-* will be really generic and independent, and the
>>> providers/a-openstack-based-provider will compose the Guice modules
>>> according to the specific requirements.
>>>
>>> Here an example:
>>>
>>> public static class Builder extends BaseProviderMetadata.Builder {
>>>
>>> protected Builder() {
>>> id("x")
>>> .name("X")
>>> .apiMetadata(new NovaApiMetadata().toBuilder()
>>> .identityName("${userName}")
>>> .credentialName("${apiKey}")
>>> .version("3")
>>> .defaultEndpoint("https://identity.x.com/v3")
>>> .endpointName("identity service url ending in /v3")
>>> .documentation(URI.create("https://x.doc.html"))
>>> .defaultModules(ImmutableSet.<Class<? extends
>>> Module>>builder()
>>> .add(KeystoneV3Module.class)
>>> .add(NovaParserModule.class)
>>> .build())
>>> .build())
>>>
>>> Notice thanks to
>>> https://github.com/jclouds/jclouds/pull/960#issuecomment-221209582 we can
>>> go even a bit further and link the Neutron context from Nova context.
>>>
>>> This means, for example, that Nova code should try to use Neutron (modern
>>> way to deal with network concepts in Openstack) but fallback to Nova
>>> security groups, if Neutron is not linked.
>>>
>>> ----
>>>
>>> This work requires to touch quite a lot of repos so I may need multiple
>>> PRs
>>> but at least we have a proposal to add KeystoneV3 support.
>>>
>>> ----
>>>
>>> I also think multiple Guice modules can be a good pattern to support
>>> multiple version of the same API, in general, not only for Openstack.
>>>
>>> ----
>>>
>>> Thanks @nacx and Richard Downer from Apache Brooklyn for the great help!
Re: Openstack Keystone v3 finally!
Posted by Ignasi Barrera <na...@apache.org>.
For those interested in this, we have now a live branch in the repo.
It supports authentication with Keystone V2 and Keystone V3 and in the
following days we'll be doing some tests on several providers and
environments.
Stay tuned to this list, the "keystonev3" branch [1], and the IRC [2]
and slack [3] channel logs for the most up to date status of this!
I.
[1] https://github.com/jclouds/jclouds/tree/keystonev3
[2] https://botbot.me/freenode/jclouds/
[3] https://the-asf.slackarchive.io/jclouds
On 20 November 2017 at 21:09, Ignasi Barrera <na...@apache.org> wrote:
> Huge effort Andrea!!!
>
> Look forward to having a look and early-testing it!
>
> On Nov 20, 2017 5:56 PM, "Andrea Turli (apache.org)"
> <an...@apache.org> wrote:
>>
>> Hi team,
>>
>> happy to say I've finally had some time to properly look at
>> https://issues.apache.org/jira/browse/JCLOUDS-114
>>
>> At the moment it still lives in my own development branch but the idea
>> here
>> is to add a Guice module for each Openstack service version jclouds
>> supports, i.e. KeystoneV2 and KeystoneV3
>>
>> I think we should break the hard-coded link with KeystoneV2 from Nova and
>> the other downstream Openstack services that require Keystone. In this
>> way,
>> the apis/openstack-* will be really generic and independent, and the
>> providers/a-openstack-based-provider will compose the Guice modules
>> according to the specific requirements.
>>
>> Here an example:
>>
>> public static class Builder extends BaseProviderMetadata.Builder {
>>
>> protected Builder() {
>> id("x")
>> .name("X")
>> .apiMetadata(new NovaApiMetadata().toBuilder()
>> .identityName("${userName}")
>> .credentialName("${apiKey}")
>> .version("3")
>> .defaultEndpoint("https://identity.x.com/v3")
>> .endpointName("identity service url ending in /v3")
>> .documentation(URI.create("https://x.doc.html"))
>> .defaultModules(ImmutableSet.<Class<? extends
>> Module>>builder()
>> .add(KeystoneV3Module.class)
>> .add(NovaParserModule.class)
>> .build())
>> .build())
>>
>> Notice thanks to
>> https://github.com/jclouds/jclouds/pull/960#issuecomment-221209582 we can
>> go even a bit further and link the Neutron context from Nova context.
>>
>> This means, for example, that Nova code should try to use Neutron (modern
>> way to deal with network concepts in Openstack) but fallback to Nova
>> security groups, if Neutron is not linked.
>>
>> ----
>>
>> This work requires to touch quite a lot of repos so I may need multiple
>> PRs
>> but at least we have a proposal to add KeystoneV3 support.
>>
>> ----
>>
>> I also think multiple Guice modules can be a good pattern to support
>> multiple version of the same API, in general, not only for Openstack.
>>
>> ----
>>
>> Thanks @nacx and Richard Downer from Apache Brooklyn for the great help!
Re: Openstack Keystone v3 finally!
Posted by Ignasi Barrera <na...@apache.org>.
Huge effort Andrea!!!
Look forward to having a look and early-testing it!
On Nov 20, 2017 5:56 PM, "Andrea Turli (apache.org)" <an...@apache.org>
wrote:
> Hi team,
>
> happy to say I've finally had some time to properly look at
> https://issues.apache.org/jira/browse/JCLOUDS-114
>
> At the moment it still lives in my own development branch but the idea here
> is to add a Guice module for each Openstack service version jclouds
> supports, i.e. KeystoneV2 and KeystoneV3
>
> I think we should break the hard-coded link with KeystoneV2 from Nova and
> the other downstream Openstack services that require Keystone. In this way,
> the apis/openstack-* will be really generic and independent, and the
> providers/a-openstack-based-provider will compose the Guice modules
> according to the specific requirements.
>
> Here an example:
>
> public static class Builder extends BaseProviderMetadata.Builder {
>
> protected Builder() {
> id("x")
> .name("X")
> .apiMetadata(new NovaApiMetadata().toBuilder()
> .identityName("${userName}")
> .credentialName("${apiKey}")
> .version("3")
> .defaultEndpoint("https://identity.x.com/v3")
> .endpointName("identity service url ending in /v3")
> .documentation(URI.create("https://x.doc.html"))
> .defaultModules(ImmutableSet.<Class<? extends
> Module>>builder()
> .add(KeystoneV3Module.class)
> .add(NovaParserModule.class)
> .build())
> .build())
>
> Notice thanks to
> https://github.com/jclouds/jclouds/pull/960#issuecomment-221209582 we can
> go even a bit further and link the Neutron context from Nova context.
>
> This means, for example, that Nova code should try to use Neutron (modern
> way to deal with network concepts in Openstack) but fallback to Nova
> security groups, if Neutron is not linked.
>
> ----
>
> This work requires to touch quite a lot of repos so I may need multiple PRs
> but at least we have a proposal to add KeystoneV3 support.
>
> ----
>
> I also think multiple Guice modules can be a good pattern to support
> multiple version of the same API, in general, not only for Openstack.
>
> ----
>
> Thanks @nacx and Richard Downer from Apache Brooklyn for the great help!
>