Github user neykov commented on the issue:
https://github.com/apache/brooklyn-server/pull/745
* re azure jclouds 2.0.1 not having enough functionality - the changes here
(and in previous PR) will create the default network, but will not assign it to
the nodes because `ipOptions` doesn't exist in `templateOptions`. That's
actually fine because 2.0.1 will create a single network for all nodes. The
behaviour this PR fixes is introduced post `2.0.1`. That's why I suggest to do
the changes against jclouds master and mark the PR as `WIP` until Brooklyn
upgrades to a new jclouds release.
* re quota failures - not waiting for the `createOrUpdate` operation to
complete will result in failures which look much like quota exceeded failures
you are seeing. The API calls are async and can return before the resource is
fully created. Attempts to use the resource in other operations will fail.
That's why its important to:
1. block for the operation to complete
2. do an effort to `createOrUpdate` the resource only once (or as little
as possible) to minimize the risk of unblocking too early while a subsequent
call re-creates the resource, putting it back in the `UPDATING` state.
Depending on the region and instance type the quota is between 10-30
instances. So I'd expect at least 10 instances to come up fine, ideally all of
them on regions that have the limit increased.
---
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.
---
