jclouds-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graeme Miller (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCLOUDS-1308) Azure ARM Default Network
Date Fri, 16 Jun 2017 13:09:02 GMT

    [ 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
> 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

View raw message