mismatched version of api for DNS-A Records

[grundrauschen]

Hello,

I was using Terraform recently to set up resources on Azure, but by recreating the cluster, I get some errors of not matching APIs now.
I tried the latest version of Terraform, which plugin imports this repository.

The message I got was the following:

azurerm_dns_a_record.tectonic-worker.1: dns.RecordSetsClient#CreateOrUpdate: Failure responding to request: StatusCode=400 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="InvalidApiVersionParameter" Message="The api-version '2016-04-01' is invalid. The supported versions are '2017-06-01,2017-05-10,2017-05-01,2017-03-01,2016-09-01,2016-07-01,2016-06-01,2016-02-01,2015-11-01,2015-01-01,2014-04-01-preview,2014-04-01,2014-01-01,2013-03-01,2014-02-26,2014-04'."

Concerning arm/dns/recordset.go for example in this repository, the APIVersion is set to 2016-04-01.

I would be glad if a solution could be found to make the sdk and terraform working again.

[marstr]

Howdy @grundrauschen, thanks for reaching out!

There are a couple of things that could be wrong, would you mind helping speed up triage by including a small repro? Mostly, I want to determine if the Go SDK is targeting the wrong endpoint or if there is a fundamental flaw in the Swagger that defines the interactions with this service. That file can be found here:

Azure/azure-rest-api-specs/specification/dns/resource-manager/Microsoft.Network/2016-04-01/dns.json

[tombuildsstuff]

Hey @grundrauschen

I tried the latest version of Terraform

In addition to what Martin has said, I just wanted to double-check a couple of things - are you referring to Terraform 0.9.11, or Terraform 0.10-rc1 with 0.1.4 of the AzureRM Provider here? In addition - which Azure region are you using out of interest?

@marstr taking a look at the error message posted above, the final version number listed in the supported versions looks suspicious to me: 2014-04 - could it be this is incorrect in this region? I'd noticed this previously and assumed it was the string being truncated - but perhaps not? ¯_(ツ)_/¯

Thanks!

[grundrauschen]

Hello @marstr,

I used Terraform 1, which recently split up the components, so there is a new repo for the AzureRM plugin 2. Because I used it yesterday with a fresh initialization, I assume, the latest release of the the plugin was used (0.1.4).

The architecture I tried to initialize with it was a Kubernetes cluster using the Tectonic installer 3, which basically contains a bunch of terraform recipes.
Because we used the tools in a quite vanilla way, I hope the links are sufficient. If not, I am happy to try to help you with the unclear points.

[grundrauschen]

@tombuildsstuff

Sure,
The error message above describes the behaviour of Terraform 0.10.0-rc1 with the 0.1.4 Azure Provider. I also tried out to use 0.9.11 before, but this resulted in the same error, but with a different version string (2015-05-04-preview)
I used Azure region West Europe for the tests yesterday, but a college of mine found the bug last week using 0.9.11 on West Europe and Azure Germany Region Northeast. Running them before (last time we recreated the cluster was round about 3 weeks ago) worked fine though.

[grundrauschen]

this might be related to: hashicorp/terraform-provider-azurerm#192

[discordianfish]

@tombuildsstuff It says '2016-04-01', so looks like support for that api version was dropped (too), at least in West Europe and/or Azure Germany Northeast.
@jdumars Any chance you can look into this again? Maybe I miss something, but it looks to me like this should also affect quite a few other customers.

[discordianfish]

Okay this is weird, according to the az cli the version should be supported:

$ az provider show --namespace Microsoft.Network | jq '.resourceTypes[]|select(.resourceType|startswith("dnszones"))'
{
  "aliases": null,
  "apiVersions": [
    "2016-04-01",
    "2015-05-04-preview"
  ],
  "locations": [
    "global"
  ],
  "properties": null,
  "resourceType": "dnszones"
}
{
  "aliases": null,
  "apiVersions": [
    "2016-04-01",
    "2015-05-04-preview"
  ],
  "locations": [
    "global"
  ],
  "properties": null,
  "resourceType": "dnszones/A"
}
{
  "aliases": null,
  "apiVersions": [
    "2016-04-01",
    "2015-05-04-preview"
  ],
  "locations": [
    "global"
  ],
  "properties": null,
  "resourceType": "dnszones/AAAA"
}
{
  "aliases": null,
  "apiVersions": [
    "2016-04-01",
    "2015-05-04-preview"
  ],
  "locations": [
    "global"
  ],
  "properties": null,
  "resourceType": "dnszones/CNAME"
}
{
  "aliases": null,
  "apiVersions": [
    "2016-04-01",
    "2015-05-04-preview"
  ],
  "locations": [
    "global"
  ],
  "properties": null,
  "resourceType": "dnszones/PTR"
}
{
  "aliases": null,
  "apiVersions": [
    "2016-04-01",
    "2015-05-04-preview"
  ],
  "locations": [
    "global"
  ],
  "properties": null,
  "resourceType": "dnszones/MX"
}
{
  "aliases": null,
  "apiVersions": [
    "2016-04-01",
    "2015-05-04-preview"
  ],
  "locations": [
    "global"
  ],
  "properties": null,
  "resourceType": "dnszones/TXT"
}
{
  "aliases": null,
  "apiVersions": [
    "2016-04-01",
    "2015-05-04-preview"
  ],
  "locations": [
    "global"
  ],
  "properties": null,
  "resourceType": "dnszones/SRV"
}
{
  "aliases": null,
  "apiVersions": [
    "2016-04-01",
    "2015-05-04-preview"
  ],
  "locations": [
    "global"
  ],
  "properties": null,
  "resourceType": "dnszones/SOA"
}
{
  "aliases": null,
  "apiVersions": [
    "2016-04-01",
    "2015-05-04-preview"
  ],
  "locations": [
    "global"
  ],
  "properties": null,
  "resourceType": "dnszones/NS"
}

[alexsomesan]

Just an observation, but it looks like even the .NET SDK is still hardcoded to that version which was just deprecated. This could be a wider problem than just in this SDK.

https://github.com/Azure/azure-sdk-for-net/blob/master/src/ResourceManagement/Dns/DnsManagement/Generated/RecordSetOperations.cs#L249

[tombuildsstuff]

@grundrauschen @discordianfish in that case would it be possible to confirm if the Terraform configuration posted here works for you, separate from Tectonic?

I've confirmed this works in West Europe, but I currently don't have access to Azure Germany to verify that (I've been trying to look into that this week)

Thanks!

[discordianfish]

@tombuildsstuff Thanks! But we decided to give up on Azure and move to AWS and our private cloud.. Thanks anyway.

[marstr]

As far as I'm aware, we don't deliberately drop support for API Versions at the service level. This is very troubling behavior. It sounds like the immediate need is outside of the scope of this repository, I'll forward on this complaint to the appropriate service teams so that they can diagnose the issue.

Thanks for getting back to me with your usage details, @grundrauschen. Sorry to hear you decided to move away from Azure, @discordianfish!

[tombuildsstuff]

Hey @grundrauschen

We've just had a similar issue opened on the Terraform Repository but for Managed Disks (hashicorp/terraform-provider-azurerm#223) and in that case a Resource Group ID was specified in place of a Resource Group Name - which returned an error similar to one you're seeing.

Would it be possible to see the Terraform Configuration that you're using to confirm if this is the same issue? I've opened hashicorp/terraform-provider-azurerm#228 which proposes adding validation to check the Resource Group Name is a Name and not an ID

Thanks!

cc @marstr

[grundrauschen]

Hey @tombuildsstuff,

I was on holidays the last weeks and therefor haven't read you message. I am sorry for that.
I am in the same team as @discordianfish, so because the company stopped the efforts on Azure, this problem is not blocking anymore.

It seems that nobody but us had the same issue here and Terraform as well as the Tectonic installer are moving forward.
Therefor I would suggest to close this ticket as obsoleted by events and if we investigate using Azure with Terraform again and stumble upon the same issue to reopen it, but until then not blocking any resources here with an open ticket.

[marstr]

Thanks for getting back to us with this, @grundrauschen. As you suggest, I'll close this issue out for now.