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!
