[jira] [Commented] (JCLOUDS-1308) Azure ARM Default Network
[ https://issues.apache.org/jira/browse/JCLOUDS-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051956#comment-16051956 ] Andrea Turli commented on JCLOUDS-1308: --- +1 for the NetworkExtension or a jclouds network abstraction > 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)
[jira] [Commented] (JCLOUDS-1308) Azure ARM Default Network
[ https://issues.apache.org/jira/browse/JCLOUDS-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051951#comment-16051951 ] Ignasi Barrera commented on JCLOUDS-1308: - The purpose of the jclouds abstractions is to provide a common interface to talk to multiple clouds. The provider-specific options are meant to be used to customize some stuff that might not be portable but that makes sense in the context of that cloud, even more if that is supported by other clouds. We need to be careful, however, about where we put the bar in those options. Providing a few to accommodate common or basic cloud features that are not available in the abstraction is good, but filling them with fine-grained options to implement provider-specific use cases is not OK. For that purpose, we have the provider-specific APIs. We could ask why should we just expose in the template options what you mention in the comment, instead of exposing the 100% of the fields and options we support in the provider API? IMO we should not make the provider-specific options that complex. That will just make the portable abstraction non-portable at all, and instead of reducing its provider-specific bits to the minimum, we would be starting a pattern of doing everything through the options, losing control, limiting the flexibility of the provider-specific API for no good reason, having more complex scenarios and more difficult to document and to understand features, and in general, the type of things we want to remove by providing a portable abstraction. I think for this case you should really use the provider-specific API to create the default network. BTW, there have been some discussions about the need for a NetworkExtension to the compute service, since many clouds have similar networking concepts: nets, subnets, elastic ips, etc. That would be a good place to start a portable way of managing the networking infrastructure. > 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)
[jira] [Commented] (JCLOUDS-1308) Azure ARM Default Network
[ https://issues.apache.org/jira/browse/JCLOUDS-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051887#comment-16051887 ] Andrea Turli commented on JCLOUDS-1308: --- Interesting point [~graemem], I think we should close this bug. Can you please open another jira issue (improvement or wish, would be appropriate, I think) where you can explain better what you are trying to achieve? Thanks! > 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)
[jira] [Commented] (JCLOUDS-1308) Azure ARM Default Network
[ https://issues.apache.org/jira/browse/JCLOUDS-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (JCLOUDS-1308) Azure ARM Default Network
[
https://issues.apache.org/jira/browse/JCLOUDS-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051463#comment-16051463
]
Ignasi Barrera commented on JCLOUDS-1308:
-
[~graemem] What about the option I mentioned about pre-creating the network?
You can do the following just once to have the default network created:
{code:java}
Subnet defaultSubnetInfo = Subnet.builder()
.name("jclouds-default-subnet")
.properties(SubnetProperties.builder().addressPrefix("10.0.0.0/24").build())
.build();
VirtualNetworkProperties defaultVnetProps = VirtualNetworkProperties.builder()
.addressSpace(AddressSpace.create(Arrays.asList("10.0.0.0/16")))
.subnets(Arrays.asList(defaultSubnetInfo)).build();
AzureComputeApi api = ctx.unwrapApi(AzureComputeApi.class);
api.getVirtualNetworkApi("the-resource-group").createOrUpdate("jclouds-default-vnet",
"region", defaultVnetProps);
Subnet defaultSubnet = api.getSubnetApi("the-resource-group",
"jclouds-default-vnet").get("jclouds-default-subnet");
{code}
And then create all VMs you want in that default subnet:
{code:java}
IpOptions ipOptions = IpOptions.builder.subnet(defaultSubnet.id()).build();
TemplateOptions options = compute.templateOptions();
Template template = compue.templateBuilder()
.options(options.as(AzureTemplateOptions.class).ipOptions(ipOptions))
...
.build();
{code}
> 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)
[jira] [Commented] (JCLOUDS-1308) Azure ARM Default Network
[ https://issues.apache.org/jira/browse/JCLOUDS-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16050753#comment-16050753 ] Andrea Turli commented on JCLOUDS-1308: --- I think jclouds should mimic as much as possible the UI experience offered by Azure portal. In particular when adding a Virtual Machine using Resource Manager the user has to either create a resource group or use a resource group already there. The default resource group or default network are not supported concepts. This is not a bug imo > 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)
[jira] [Commented] (JCLOUDS-1308) Azure ARM Default Network
[ https://issues.apache.org/jira/browse/JCLOUDS-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16050722#comment-16050722 ] Graeme Miller commented on JCLOUDS-1308: hello, thank you both for your comments. I had a bash at adding back the default network, you can see the changes [here|https://github.com/Graeme-Miller/jclouds-labs/commit/f32df4f9f0ec096024e49c7c35b082043c410eb5] to get an idea of what I am thinking. Any comments would be appreciated. [~nacx] for our use case, we want VMs in different groups to be deployed to the same network by default (as was previously the case with Azure ARM). I totally understand that the current implementation is better than the previous one, for the reasons you have stated- but it would be cool if we could keep the default network approach as it was quite handy. > 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)
[jira] [Commented] (JCLOUDS-1308) Azure ARM Default Network
[
https://issues.apache.org/jira/browse/JCLOUDS-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (JCLOUDS-1308) Azure ARM Default Network
[
https://issues.apache.org/jira/browse/JCLOUDS-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
