azurerm_cost_anomaly_alert - Support for scoping alert to a specific subscription_id

[daniel-edwards-nz]

Fixes #23673

Added new required parameter subscription_id to the azurerm_cost_anomaly_alert resource which allows creation of alerts on subscriptions other than the one specified in the provider config.

I'd initially hoped to make this an optional parameter and use the provider's subscription as a default but I ran in to trouble getting the read function to work appropriately under those circumstances. As such, anyone using this already would need to update their config to include the subscription_id.

I'm somewhat new to Go and this is my first contribution here so all feedback is appreciated :-)

Test results:

=== RUN   TestAccResourceAnomalyAlert_update
=== PAUSE TestAccResourceAnomalyAlert_update
=== CONT  TestAccResourceAnomalyAlert_update
--- PASS: TestAccResourceAnomalyAlert_update (124.11s)
PASS
ok      [github.com/hashicorp/terraform-provider-azurerm/internal/services/costmanagement](http://github.com/hashicorp/terraform-provider-azurerm/internal/services/costmanagement)        127.855s

=== RUN   TestAccResourceAnomalyAlert_requiresImport
=== PAUSE TestAccResourceAnomalyAlert_requiresImport
=== CONT  TestAccResourceAnomalyAlert_requiresImport
--- PASS: TestAccResourceAnomalyAlert_requiresImport (55.27s)
PASS
ok      [github.com/hashicorp/terraform-provider-azurerm/internal/services/costmanagement](http://github.com/hashicorp/terraform-provider-azurerm/internal/services/costmanagement)        58.866s

[katbyte]

Thanks for the pr @daniel-edwards-nz - this PR as is would be a breaking change, something we cannot do till a major version.

You should be able to make it optional and the only include the scope property in the payload if it is set and not empty?

[katbyte]

Thanks for the changes @daniel-edwards-nz - looking better but you are correct about the read - what i think can be done instead is make the property computed and then you don't have to try and conditionally set it in read

[daniel-edwards-nz]

Thanks for the suggestions @katbyte. I've added those changes and re-run the tests and it appears to be all functioning correctly now. Let me know if you spot anything else needed :-)

[daniel-edwards-nz]

Hi @katbyte, sorry for the extra ping, just wondering if you might be able to review this again please? If there are any further changes needed before this can be merged please let me know.

[katbyte]

Thanks @daniel-edwards-nz - LGTM 🍵

[williamarobinson]

This is great! Do you feel that this code could be used for additional resources? There are some other resources that would benefit from the subscription ID being a possible variable.
azurerm_monitor_activity_log_alert
azurerm_key_vault_secret (when going across subscriptions)

[daniel-edwards-nz]

@williamarobinson, I'm glad this will be helpful :-)

While I think it could be possible to apply this same methodology to other resources my personal opinion (I'm not a project maintainer though so I can only speak for myself, not the project) is that in most cases that would be a bad idea and it would seem to go against the principles of the provider. In general the subscription is configured in one place only, in the provider config, which makes it consistent across all resources and easy to understand and use. There are obviously places where that can create frustrations though, particularly for things that cross subscription boundaries or are desirable to set up in a multi-subscription platform such as these cost alerts.

One of the main reasons I felt it was appropriate in this case is that these alerts can only be created at a subscription scope - not resource group or management group etc. This means there is very little room for it to be misunderstood or misused if the variable is added here. The value can also be automatically computed quite easily if it isn't supplied (eg. get the current provider configured subscription). To add a subscription variable for most other resources would likely lead to confusion and difficulty to set up roles and permissions etc too. The existing mechanism of a second provider configured with another subscription and used as an alias should cover the majority of use-cases.

However I think that this should be able to be implemented on a case-by-case basis for specific resources where it makes sense to do so. Particularly for those that may operate outside the traditional scope of a subscription but still need to interact with a subscription somehow. I'd be keen to explore other areas where it might be useful :-)

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.