azurerm_subscription: prevent cancellation of existing subscriptions on destroy

[josh-barker]

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 -v
Terraform v1.1.7
on darwin_amd64
+ provider registry.terraform.io/hashicorp/azurerm v2.98.0

Affected Resource(s)

• azurerm_subscription

Terraform Configuration Files

resource "azurerm_subscription" "example" {
  subscription_name = "My Example Subscription"
  subscription_id   = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" # existing subscription id
}

Expected Behaviour

As the subscription was not imported, I expect that the subscription should not have been cancelled.

Actual Behaviour

The subscription was cancelled.

Steps to Reproduce

1. terraform apply
2. terraform destroy

References

• An idea to create another resource was discussed in Slack with Tom and this is the link to the thread.

[manicminer]

Hi @josh-barker, thanks for raising this and for the proposed PR. I agree that it might be useful to have the option of different behavior here, however in of itself this is not considered a bug.

Resources imported into your Terraform state are treated exactly the same as resources which were created by Terraform in the first place. There is objectively no way to tell the difference between a once-imported resource and one that was never imported, and subjectively no reason to do so, since managing infrastructure with Terraform implies the same workflow regardless.

I have commented in more detail on your PR #15752, however if you'd like to propose such a behavioral change you are welcome to open a new feature request in that vein for discussion.

Accordingly, since this is expected behavior, I"m going to close this issue for now but as mentioned please feel free to write a feature request. Thanks!

[josh-barker]

Hey @manicminer, thanks for reviewing and responding to the issue & PR.

I originally raised this a while ago in the Slack channel, discussed with Tom Harvey and he suggested making a new resource.

I find the current implementation of the subscription resource is a bit different.
There are a few scenarios:

1. Creating new subscriptions.
2. Importing an existing subscription.
3. adding-an-alias-to-an-existing-subscription. This allows properties of an existing subscription to be managed.

In scenarios 1 and 2, I would expect like all other resources that Terraform will create, update and delete the resource.

However, scenario 3 is unusual.
I'm able to manage an existing subscription without importing it.
The outcome I'm trying to achieve is to be able to manage the subscription name and tags.

I like your idea of using a provider flag to disable subscription cancellations.

How does the below definition proposal look?
Potentially, the flag could only apply when a subscription_id is specified.

provider "azurerm" {
    features {
        subscription {
           prevent_cancel_subscription = true # defaults to false
           # or 
           prevent_cancel_existing_subscription = true # defaults to false
        }
    }
}

Cheers

[manicminer]

Hi @josh-barker, that schema proposal looks pretty good to me. I'd probably suggest calling the property prevent_cancellation_on_destroy which is perhaps more aligned with the names of other features. Since there's no way to distinguish between an imported (or auto-adopted) resource, or one created by Terraform, the behavior would be the same for all resources.

[github-actions]

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.