jclouds-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ignasi Barrera <n...@apache.org>
Subject Re: Openstack Keystone v3 finally!
Date Thu, 11 Jan 2018 15:53:47 GMT
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 <nacx@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 <nacx@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)"
>> <andreaturli@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!

Mime
View raw message