Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Azure displays SKU as "Standard" but when running Terraform plan it tries to change it to "standard" #7254

Closed
aport1996 opened this issue Jun 8, 2020 · 9 comments
Assignees
Labels

Comments

@aport1996
Copy link

aport1996 commented Jun 8, 2020

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform (and AzureRM Provider) Version

Terraform v0.12.26

Affected Resource(s)

  • azurerm_key_vault

Expected Behavior

In Azure, the SKU Name is set as "Standard", the same is for resources like azurerm_public_ip. But with this resource, we see that when running terraform plan it tries to change "Standard" to "standard". We are not sure if this is a normal behaviour or not, as if we try with "Standard" it will not accept it. Could you please clarify if maybe in the past this was changed and now it's normal to just leave "standard" for this resource type? (we also manually changed the values of sku from "Standard" to "standard" in the tfstate but terraform still tries to change the values after we re-import the related modules).

We have a similar issue also with another resource azurerm_application_gateway

authentication_certificate {
name = "name"
data = "xxx"
}

Here terraform tries to add the "data" parameter even though it's already there in the terraform state. The output of the terraform plan in this case is ~data=(sensitive value) and we don't understand why it's trying to do it. Although I understand this might be harmless, I would like to understand why terraform still tries to edit it.

Actual Behavior

In the terraform plan output, only for the above keyvault resource terraform tries to change the SKU name from "Standard" to "standard"

Steps to Reproduce

  1. Add sku_name as "Standard"
  2. Run terraform plan
  3. Output:

Error: expected sku_name to be one of [standard premium], got Standard

in resource "azurerm_key_vault" "name"

  1. Change sku_name to "standard" and run terraform plan again:
    Output:
    ~ sku_name = "Standard" -> "standard"

For the moment we used "ignore_changes" in lifecycle to work around it.

Important Factoids

  • N/A

References

  • N/A
@mybayern1974 mybayern1974 added the service/key-vault Key Vault label Jun 9, 2020
@magodo magodo self-assigned this Jun 9, 2020
@magodo
Copy link
Collaborator

magodo commented Jun 9, 2020

@Nyxbiker Thank you for letting us know this issue 👍
From your description above, I think you have two questions:

  1. Why is sku_name of azurerm_key_vault fixed to be standard other than Standard?
  2. Why is authentication_certificate.name of azurerm_application_gateway is shown as (sensitive value) in plan output?

For question 1, I assume you have a terraform config first, then import the resource into terraform's management. At this point, you make a terraform plan and see the output telling you that it only allows sku_name to be standard. The reason is the schema definition only allow standard literally, which is the definition of Azure API of keyvault:

https://github.com/terraform-providers/terraform-provider-azurerm/blob/09bcf4b1f952a91247b7432434f1138e42e81a10/azurerm/internal/services/keyvault/key_vault_resource.go#L72

Regarding to why you can import it without issue is because during terraform import, it only refer to "address" (e.g. "azurerm_keyvault.example"), but will not do any validation on your config.
So the suggestion is that you just change your config to using standard.

For question 2, it is because that property is defined as sensitive in schema definition:

https://github.com/terraform-providers/terraform-provider-azurerm/blob/09bcf4b1f952a91247b7432434f1138e42e81a10/azurerm/internal/services/network/application_gateway_resource.go#L697

@aport1996
Copy link
Author

Hi @magodo

Thanks for your reply!

I fully understand those properties are clearly defined in the API and schema definitions, but I was more questioning why although we manually set in the terraform state the "sku_name" to "standard" terraform still outputs that it's trying to change it from "Standard" to "standard", although there is no "Standard" value anymore in the state file.

The same thing happens for the authentication_certificate "data" value, I added it manually in the terraform state file but I don't understand why Terraform still tries to add it in as if the value was not actually there.

To clarify, these resources are already deployed on Azure with such plan (for the keyvault) and value (for the authentication certificate), and I'm trying to make sure that when terraform plan runs it sees that the infrastructure is up to date.

My issue seems similar to this one -> #7215

@ghost ghost removed the waiting-response label Jun 9, 2020
@magodo
Copy link
Collaborator

magodo commented Jun 10, 2020

@Nyxbiker I failed to reproduce this issue, would you please kindly provide the detailed steps to reproduce this issue from scratch, including the config and the step to create this resource? I assume this might not be a 100% reproducible issue, maybe because of the resource under question is a long existed resource?
Besides, may I know which provider version you are using?

@phatcher
Copy link

@magodo I hit this yesterday and in my case the key vaults were created via the Azure portal within the last week, so it could be that the portal is not providing the lower case value to the api?

The azure rmprovider I'm using is 2.0.0

If I export the ARM template I get the following...

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "vaults_xxx_name": {
            "defaultValue": "kv-xxx",
            "type": "String"
        }
    },
    "variables": {},
    "resources": [
        {
            "type": "Microsoft.KeyVault/vaults",
            "apiVersion": "2016-10-01",
            "name": "[parameters('vaults_xx_name')]",
            "location": "northeurope",
            "properties": {
                "sku": {
                    "family": "A",
                    "name": "Standard"
                },
            ...
            }
        ...
        }
    ]
    ...
}

Let me know if you need anything else

@ghost ghost removed the waiting-response label Jun 10, 2020
@phatcher
Copy link

As this was a new kv, I applied the changes and the sku does go from Standard -> standard and terraform considers it stable after that.

@magodo
Copy link
Collaborator

magodo commented Jun 11, 2020

@phatcher The cause is that API allow case-insensitive Sku.name, that means we need to align with API behavior in provider code.
(PS: I should have came up with this idea in the first place, thank you for guiding me with the detailed steps to reproduce 😄 )

@phatcher
Copy link

NP

@tombuildsstuff
Copy link
Contributor

Fixed via #8983

@ghost
Copy link

ghost commented Jan 15, 2021

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!

@ghost ghost locked as resolved and limited conversation to collaborators Jan 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants