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 <n...@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)" > <andreatu...@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!
