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