[
https://issues.apache.org/jira/browse/JCLOUDS-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049272#comment-16049272
]
Svetoslav Neykov commented on JCLOUDS-1308:
-------------------------------------------
Having a shared network makes sense as that's how nodes behave in other clouds.
Different groups can see each other by default.
The problem is that Azure doesn't have a default vnet+subnet where jclouds can
safely assume it should add nodes if not otherwise specified. The possible
solutions I see are:
1) As suggested in the description have a jclouds create a default
vnet+subnet to add nodes to
2) Support vnet + subnet templateOptions which create the network if missing
3) GCE **requires** that the user specify {{networks}} during deployment as
it doesn't have a default network as well. Unfortunately this requires a manual
setup step on every account jclouds is to be used on, so not ideal.
Slight preference to (1). A network that is created once and not deleted
afterwards (i.e. the old behaviour).
We could try to check if the network is used and delete it if it's the last
node using it. This would introduce concurrency problems and lead to deployment
failures so I prefer not to do it at all.
Re resource groups - I think it makes sense to create a resource group per node
group. Makes bookkeeping a bit easier and is also easier to track the resources
in the UI.
> 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)
