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

azurerm_service_plan not supporting skus that are available in the portal #26853

Open
1 task done
ikatergaris opened this issue Jul 29, 2024 · 2 comments
Open
1 task done

Comments

@ikatergaris
Copy link

ikatergaris commented Jul 29, 2024

Is there an existing issue for this?

  • I have searched the existing issues

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 comments along the lines of "+1", "me too" or "any updates", 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 and review the contribution guide to help.

A client of mine has changed an azurerm_service_plan deployed via terraform to use a specific sku (I1mv2)
Image from terraform plan -refresh-only. Initialy deployed as sku I1v2
image

When I try to correct the problem by editing the config
Image from terrafrom plan
image

An "as soon as possible" fix, much appreciated

Kindest regards, Ioannis

Please note: The sku isn't available on my portal as well. The client has an entrerprise agreement and that might have something to do with it. Or it might not! The client however has selected it and I would rather keep it that way.

This new sku isn't available for me to select when using terraform

Terraform Version

1.8.3

AzureRM Provider Version

3.113.0

Affected Resource(s)/Data Source(s)

azurerm_service_plan

Terraform Configuration Files

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "example" {
  name     = "example-resources"
  location = "West Europe"
}

resource "azurerm_service_plan" "example" {
  name                = "example"
  resource_group_name = azurerm_resource_group.example.name
  location            = azurerm_resource_group.example.location
  os_type             = "Windows"
  sku_name            = "I1mv2"
}

Debug Output/Panic Output

The pics in the message show exactly what the problem is. Don't think a debug would help more

Expected Behaviour

No response

Actual Behaviour

No response

Steps to Reproduce

No response

Important Factoids

No response

References

No response

@Chambras
Copy link
Contributor

@ikatergaris Do you know what region your client was using? some SKUs are available in some regions firsts and then eventually roll out to all regions. Was he using a different region from what you are using?

@ikatergaris
Copy link
Author

@ikatergaris Do you know what region your client was using? some SKUs are available in some regions firsts and then eventually roll out to all regions. Was he using a different region from what you are using?

Good point generally but not applicable in this situation. We are mostly concerned with troubleshooting terraform's behavior. The resource was originally created in region A using terraform. The client changed just the sku from X to Y from the portal. Terraform refresh-only sees this change. You try to use sku Y in your code in order to prevent the change back to sku X and you get a validation error back, saying that you cannot choose sku Y. The resource never moved from region A. I tried doing a portal install in region A, but the sku wasn't available for me. The client however has the option and has selected it. Maybe because of the enterprise agreement. Maybe some other reason. I think it might just be a case of adding sku Y to the validation checks on the provider. Together with other missing sku's. I2mv2, I3mv2 and so on. The one I'm interested in is I1mv2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants