[
https://issues.apache.org/jira/browse/JCLOUDS-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
