brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From neykov <>
Subject [GitHub] brooklyn-server issue #745: Azure ARM default network fixes from PR suggesti...
Date Mon, 26 Jun 2017 15:52:37 GMT
Github user neykov commented on the issue:
    * 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 or file a JIRA ticket
with INFRA.

View raw message