Feature request: Support for traffic manager / Load balancer

[dhilton]

We have a use case where we'd like to use Terraform to create traffic managers / load balancers in Azure. To support this we need this client library to support it, so terraform can then support it via the stable library that it currently depends on.

I've seen mention in some of the other issues of a auto API code generation, does that mean that you wouldn't accept a PR to add this?

[ahmetb]

@dhilton I believe if the API is under the Resource Manager APIs, we will have code generation for that coming up soon. Therefore it's unlikely we'll merge (although you can always do external packages or maybe we can merge into a dev branch). If it's part of Service Management APIs, we can still accept a PR.

[dhilton]

It is - any idea on when that code generation will merge into master? Because that solves a couple of other issues I have or rather enables them to be solved rather quickly.

[ahmetb]

cc: @brendandixon to give an update.

[brendandixon]

We hope to have an early alpha sometime in the next three weeks. However, what will be included is still being worked out. Our code generation process is still underdevelopment.

[dhilton]

Ah cool - thanks for the update, if there is anything I can do to help please just point at a repo/branch here. Good luck with the coding.

[brendandixon]

Thanks. We'll likely post a blog somewhere (possibly at https://ahmetalpbalkan.com) once it's available. Stay tuned!

[proffalken]

We're also very interested in this.

We're in the process of moving some of our Terraform code from AWS to Azure and load-balancing/traffic managers are definitely something that we need! :)

[dhilton]

Waves @proffalken we should swap notes some time, our code is here: https://github.com/alphagov/tsuru-terraform

[brendandixon]

@dhilton We've released the initial set of ARM Go packages. They are generated from Swagger definitions found here: https://github.com/Azure/azure-rest-api-specs. We do not yet have a Swagger definition file for the DNS REST API (see https://msdn.microsoft.com/en-us/library/azure/mt163862.aspx), but you can use ARM templates through the arm/resources package. I would go that route for now.

[dhilton]

OK cool - what's the versioning approach with that repo? I.e. If it's used as a dependency, is it likely to add any breaking changes or will it simply be a matter of adding extra API's to the client library? Is this the new preferred client lib to Azure?

[ahmetb]

@dhilton right now none of the packages have a backwards compatibility or versioning story. If you take a look at the repo it consists of several totally independent packages storage, arm and management (asm). Among those, storage and management have been fairly stable in the past 3-4 months and they had an almost complete rewrite recently so I don't expect those to break.

On the other hand, arm package is likely to break based on user comments we're currently collecting. That package is auto-generated and is in an alpha state; whereas you can call others beta or above.

As you can imagine, when you have 3 separate packages, versioning/tagging is a bit tricky as each have their own release cycles. But we'll be introducing versioning through tags soon.

Bottomline is, if you are relying on current snapshot of the repo, please use godep/gb etc. to vendor this snapshot (commit) of the repo (meaning, have a local copy of this repo in your project). Soon when we start using tags (will probably release a 2.0), you can vendor the tags directly and read the changelogs (also we'll start doing this) to see if you actually need to update the vendored version. Does that answer your question?

[brendandixon]

@dhilton This is addressed in the v0.2.0-beta version of the ARM packages. Let us know if there remain issues!

[garimakhulbe]

Old issue. This is added in Azure Go SDK. Closing this.

https://github.com/Azure/azure-sdk-for-go/tree/master/arm/trafficmanager