[
https://issues.apache.org/jira/browse/JCLOUDS-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049269#comment-16049269
]
Ignasi Barrera commented on JCLOUDS-1308:
-----------------------------------------
The old implementation presented several issues:
* jclouds only considered one resource group, and that make it impossible to
let jclouds created resources to interact with existing ones. This also meant
that scenarios where people use a resource group for storage, another for
networking, etc, didn't work with jclouds. We were limiting the resource group
layout, which was not good and prevented us from being usable in most cases,
where accounts are not empty.
* Having one default network was not flexible enough. There was no way to
create several subnets and jclouds VMs were always attached there (you could
specify a virtual network but not a subnet).
* VMs could not be attached to several subnets, nor get different addresses.
They were always assigned a private IP and a dynamic Public IP. Now that can be
configured too.
The current approach fixes all these issues, is more flexible and you should be
able to achieve the same behavior:
* You can create all your VMs in the same "jclouds group", and all VMs should
go to the same default network. jclouds creates one Resource Group per jclouds
group *unless you set the _options.ResourceGroup_* template option. You can
play with that.
* You can pre-create the default network and subnet where you want your VMs to
be attached to, and then provide the convenient template options to let all VMs
be attached there:
{code:java}
IpOptions ipOptions = IpOptions.builder.subnet("the
subnet").allocatePublicIp(true/false).build();
options.as(AzureTemplateOptions.class).ipOptions(ipOptions);
{code}
> Azure ARM Default Network
> -------------------------
>
> Key: JCLOUDS-1308
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1308
> Project: jclouds
> Issue Type: Bug
> Reporter: Graeme Miller
>
> 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)
