brooklyn-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [3/3] brooklyn-server git commit: Closes #745
Date Tue, 04 Jul 2017 11:31:53 GMT
Closes #745

Azure ARM default network fixes from PR suggestions

Important Note: Azure ARM doesn't currently work with the master of Brooklyn. Currently, after
a Azure ARM VM is created, JClouds attempts to list all of the nodes in the resource group
but cannot parse the result due to a missing property (vhd for DataDisk). I have tested with
the latest JClouds code in master and we do not have this issue.

However, we are currently on the latest released version of JClouds (2.0.1) and we cannot
pull in the code in mater until there is another JClouds release. As such, the code that has
been written for default network has been written against the code in JClouds master and will
work when we upgrade to the next version of JClouds. If you need working Azure ARM support,
and default networking build JClouds master locally, and build brooklyn against it.


Various fixes:
- IpOptions were being added incorrectly to templateOptions. They were being set as a map,
when they should have been a list of maps
- When checking templateOptions for existing config, look for 'networks' rather than NETWORK_NAME
config (which resolves to 'networkName'). Still use NETWORK_NAME config when checking in brooklyn
- Check that a region has been set in brooklyn config (config.get(CLOUD_REGION_ID)) if not,
don't try and create a default network. It was suggested that I could move the default network
creation to later in JCloudsLocation after the templateOptions have been built. This would
mean that a default region would have been added to the templateOptions if none was specified
in config. I attempted to implement this, but ran into an issue. The AzureTemplateOptions
in JClouds 2.0.1 is different to the AzureTemplateOptions in JClouds master. As such, it is
not possible to amend the AzureTemplateOptions from Brooklyn code, as we would not be able
to modify the ipOptions (a concept that only exists in JClouds master). As such, I have put
the null check in for the time being. After the next JClouds release, I will come back and
fix this
- Check for the situation where a default network exists, but a default subnet does not. In
this situation create a default subnet only


@neykov pointed out there could be issues if we are trying to create multiple VM's at the
same time due to the these VMs all trying to create the default network/subnet. I have investigated
and I don't think this will be an issue. The default network creation is done in the obtainOnce
method of JCloudsLocation. If there were a situation where multiple VMs tried to create the
network at the same time, then all but one would fail. Brooklyn will by default will then
attempt to get a VM again, and this time it will succeed. To test this theory I spooled up
three AMPs, and at the same time kicked off a deployment of 5 VMs on each AMP (15 total) to
try and force this situation. Only 3/15 came up correctly, but the failures were quota issues
which means they got passed network creation.


Branch: refs/heads/master
Commit: eb9795c1316681bc2e0b47ca584d026f22f3a92c
Parents: 3d8675e 6d40d63
Author: Svetoslav Neykov <>
Authored: Tue Jul 4 14:31:36 2017 +0300
Committer: Svetoslav Neykov <>
Committed: Tue Jul 4 14:31:36 2017 +0300

 .../creator/  | 79 +++++++++++++-----
 .../      | 88 +++++++++++++++-----
 2 files changed, 126 insertions(+), 41 deletions(-)

View raw message