GitHub user Graeme-Miller opened a pull request:

    https://github.com/apache/brooklyn-server/pull/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 config
    - 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.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/Graeme-Miller/brooklyn-server 
fix_azure_default_network

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/brooklyn-server/pull/745.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #745
    
----
commit 923f452b18b415c39cd7b4f71768953091132f3f
Author: graeme.miller <graeme.mil...@cloudsoftcorp.com>
Date:   2017-06-23T11:53:41Z

    Azure ARM default network fixes from PR suggestions

----


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Reply via email to