[
https://issues.apache.org/jira/browse/JCLOUDS-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16051868#comment-16051868
]
Graeme Miller commented on JCLOUDS-1308:
----------------------------------------
Thanks all for your comments.
[~nacx] thanks for the suggestion, I am looking into that as a backup option.
[~andreaturli] that's a very interesting point, I didn't realise that was a
design principle behind JClouds but it makes sense. So when a user is creating
a VM through the Azure UI they are able to create a network/subnet. Would it be
acceptable to replicate that in JClouds. I.E. if there is a network specified
in TemplateOptions that does not exist we create it.
In more detail, I propose:
*) Modifying IpOptions so that a user can specify a NetworkName, SubnetName and
NetworkResourceGroup (optional, will use groups resource group if not specified)
*) We either replace the current subnet config (which is actually a subnet
resource id) or we keep it and make it mutually exclusive with the above
*) If the NetworkName/Subnet name does not exist we create it in the
NetworkResourceGroup. We would do that in the normalizeNetworkOptions method
[here|https://github.com/jclouds/jclouds-labs/blob/master/azurecompute-arm/src/main/java/org/jclouds/azurecompute/arm/compute/strategy/CreateResourcesThenCreateNodes.java#L219]
> Azure ARM Default Network
> -------------------------
>
> Key: JCLOUDS-1308
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1308
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-compute
> Affects Versions: 2.0.1
> Reporter: Graeme Miller
> Labels: azurecompute-arm
>
> For Azure ARM, the default behaviour when creating a VM has changed with
> regards to VNETs/Subnets.
> Previously, if no networking configuration was provided JClouds would create
> a default VNET per region. The implementation of this can be found
> [here|https://github.com/jclouds/jclouds-labs/blob/4f50e7d65a6d7e1a3d06efcf557b363e55118238/azurecompute-arm/src/main/java/org/jclouds/azurecompute/arm/compute/strategy/CreateResourceGroupThenCreateNodes.java#L147].
> This was useful as it meant that a user could rely on VMs being able to
> access one another on their subnet IP addresses, even when a network was not
> provided (I believe this is the same as other clouds, but I am not too
> familiar with JClouds).
> Now, when no networking configuration is provided we create a VNET per group
> id. For our usage, this is a bit of a problem as it means by default each VM
> is getting it’s own network.
> To see a history of these changes please see the commit
> [here|https://github.com/jclouds/jclouds-labs/commit/54e5ce50a43250c4f87414506b3bba4d8365284e]
> that moved to having a VNET per resource group and then
> [here|https://github.com/jclouds/jclouds-labs/commit/dbadb279f14848f21879f7eb6c7136e1a5f11192],
> that moved to using just the groupID.
> I propose we go back to the old way, where we have a default resource group,
> VNET and subnet per region. This will mean that by default, VMs will be able
> to speak to each other on there private IPs. If that is not possible, could
> we have a template option that will allow us to turn this behaviour on?
> I am very happy to work on the solution myself, but would like direction form
> the community before investing too much time.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
