trevorflanagan commented on this pull request.
> @@ -79,17 +74,21 @@ protected GetOrCreateNetworkDomainThenCreateNodes(final
> CreateNodeWithGroupEncod
final DimensionDataCloudControlTemplateOptions templateOptions =
template.getOptions()
.as(DimensionDataCloudControlTemplateOptions.class);
- String networkDomainName =
firstNonNull(templateOptions.getNetworkDomainName(),
DEFAULT_NETWORK_DOMAIN_NAME);
- String vlanName = firstNonNull(templateOptions.getVlanName(),
DEFAULT_VLAN_NAME);
+ final Set<String> networks = templateOptions.getNetworks();
+
+ String networkDomainName = firstNonNull(!networks.isEmpty() ?
networks.iterator().next() : null,
+
DimensionDataCloudControlTemplateOptions.DEFAULT_NETWORK_DOMAIN_NAME);
@nacx the change I have made appears to be incorrect. In DD model a Server can
be attached to many Vlan. A Vlan is associated with a single Network Domain
only. A Server can only be associated with Vlans on the **same** Network Domain.
I think that recording the lists of VLANs in `templateOptions.network` might
be a better approach. My thoughts are that we revert the change to revert the
`networkDomainName` removal from `DimensionDataCloudControlTemplateOptions`
Replace `DimensionDataCloudControlTemplateOptions vlanName` with
`templateOptions.network`
I do have a question though about what exactly we store in
`templateOptions.network`. We could store the Vlans for a given Network Domain
name
`org.jclouds.dimensiondata.cloudcontrol.features.NetworkApi#listVlans(java.lang.String)`
**OR** we could use a Server to retrieve this information and therefore reduce
the set of Vlans we store in `templateOptions.network`. Just not sure what you
think is the best approach?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/426#discussion_r157430700
