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_monitor_metric_alert supports multiple scopes and different criteria #7159

Merged
merged 9 commits into from Jul 16, 2020

Conversation

magodo
Copy link
Collaborator

@magodo magodo commented Jun 1, 2020

Originally, the resource only allows users to specify one scope. Furthermore, it only allows the user to specify static criteria, while there are dynamic criteria and "web test location availability" criteria.
This PR tries to support both facets and not to introduce breaking change.

The complex part of kinds of criteria is that there are two levels of discriminator defined in swagger, as shown below:

monitor_metric_alert_criteria

Previous code was using the SingleResourceMultipleMetricCriteria, while this is superseded by MultipleResourceMultipleMetricCriteria, which in turns derives into StaticMetricCriteria (actually MetricCriteria, which was underused) and DynamicMetricCriteria. Additionally, there is another criteria WebtestLocationAvailabilityMetricCriteria. In order to keep schema use to use and (most importantly) to keep backward compatibility, I defined three criteria in schema:

  • criteria: same as before represents the StaticMetricCriteria. Each alert can specify one or more criteria.
  • dynamic_criteria: represents the DynamicMetricCriteria. Each alert can only have one such criterion.
  • webtest_location_availability_criteria: represents WebtestLocationAvailabilityMetricCriteria. Each alert can only have one such criteria.

And then set them Optional and add the ExactlyOneOf constraints among them.

Another change is that I added two more attributes called target_resource_type and target_resource_location, which are mandatory when either multiple scopes are set or the subscription/resource group scope is specified, in which case the service need to use this information to identify the resource type and resource location.

Test Result

💤 via 🦉 v1.14.3 make testacc TEST=./azurerm/internal/services/monitor/tests TESTARGS="-run TestAccAzureRMMonitorMetricAlert_"
==> Checking that code complies with gofmt requirements...
==> Checking that Custom Timeouts are used...
==> Checking that acceptance test packages are used...
TF_ACC=1 go test ./azurerm/internal/services/monitor/tests -v -run TestAccAzureRMMonitorMetricAlert_ -timeout 180m -ldflags="-X=github.com/terraform-providers/terraform-provider-azurerm/version.ProviderVersion=acc"
=== RUN   TestAccAzureRMMonitorMetricAlert_basic
=== PAUSE TestAccAzureRMMonitorMetricAlert_basic
=== RUN   TestAccAzureRMMonitorMetricAlert_requiresImport
=== PAUSE TestAccAzureRMMonitorMetricAlert_requiresImport
=== RUN   TestAccAzureRMMonitorMetricAlert_complete
=== PAUSE TestAccAzureRMMonitorMetricAlert_complete
=== RUN   TestAccAzureRMMonitorMetricAlert_basicAndCompleteUpdate
=== PAUSE TestAccAzureRMMonitorMetricAlert_basicAndCompleteUpdate
=== RUN   TestAccAzureRMMonitorMetricAlert_multiScope
=== PAUSE TestAccAzureRMMonitorMetricAlert_multiScope
=== CONT  TestAccAzureRMMonitorMetricAlert_basic
=== CONT  TestAccAzureRMMonitorMetricAlert_basicAndCompleteUpdate
=== CONT  TestAccAzureRMMonitorMetricAlert_multiScope
=== CONT  TestAccAzureRMMonitorMetricAlert_complete
=== CONT  TestAccAzureRMMonitorMetricAlert_requiresImport
--- PASS: TestAccAzureRMMonitorMetricAlert_complete (160.67s)
--- PASS: TestAccAzureRMMonitorMetricAlert_basic (165.03s)
--- PASS: TestAccAzureRMMonitorMetricAlert_requiresImport (174.56s)
--- PASS: TestAccAzureRMMonitorMetricAlert_basicAndCompleteUpdate (344.57s)
--- PASS: TestAccAzureRMMonitorMetricAlert_multiScope (558.28s)
PASS
ok      github.com/terraform-providers/terraform-provider-azurerm/azurerm/internal/services/monitor/tests       558.329s

(fxes #3719, fixes #3886)

… criterias

Originally, the resource only allows user to specify one scope.
Furthermore, it only allow user to specify static criteria, while there
are dynamic criterias and "webtest available location" criterias.

This PR tries to support both facets and not to introduce breaking
change.
@AdamCoulterOz
Copy link
Contributor

:-( got pushed back a week ... was hanging on this one...

* `operator` - (Required) The criteria operator. Possible values are `LessThan`, `GreaterThan` and `GreaterOrLessThan`.
* `alert_sensitivity` - (Required) The extent of deviation required to trigger an alert. Possible values are `Low`, `Medium` and `High`.
* `dimension` - (Optional) One or more `dimension` blocks as defined below.
* `evaluation_total_account` - (Optional) The number of aggregated lookback points. The lookback time window is calculated based on the aggregation granularity (`window_size`) and the selected number of aggregated points.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo here, should be evaluation_total_count

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, Thank you!

@AdamCoulterOz
Copy link
Contributor

@katbyte can i confirm if this will make the cut for 2.16?

@tombuildsstuff tombuildsstuff modified the milestones: v2.16.0, v2.17.0 Jun 25, 2020
@AdamCoulterOz

This comment has been minimized.

@mholttech

This comment has been minimized.

@dbehnood

This comment has been minimized.

Copy link
Member

@tombuildsstuff tombuildsstuff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a few comments whilst passing through


return []interface{}{
map[string]interface{}{
"webtest_id": webtestID,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this make more sense as web_test_id?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think webtest is a better fit as it emphasize it is special name called webtest, rather than some test of web?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there's an existing resource for this with web_test - so it'd be worth making this consistent to be clearer

arguably this could make sense as application_insights_web_test_id rather than such a generic name?

Copy link
Collaborator Author

@magodo magodo Jul 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll rename the criteria name (the name of the nested block) into application_insights_web_test_location_availability_criteria, and keep the including attributes still (e.g. component_id), except renaming the included webtest_id into web_test_id.

@katbyte katbyte modified the milestones: v2.18.0, v2.19.0 Jul 10, 2020
@magodo
Copy link
Collaborator Author

magodo commented Jul 11, 2020

Hey @tombuildsstuff Thank you for your review!
I have updated the code accordingly, please take a look!

Test Result

💤 make testacc TEST=./azurerm/internal/services/monitor/tests TESTARGS="-run=TestAccAzureRMMonitorMetricAlert_multiScope"
==> Checking that code complies with gofmt requirements...
==> Checking that Custom Timeouts are used...
==> Checking that acceptance test packages are used...
TF_ACC=1 go test ./azurerm/internal/services/monitor/tests -v -run=TestAccAzureRMMonitorMetricAlert_multiScope -timeout 180m -ldflags="-X=github.com/terraform-providers/terraform-provider-azurerm/version.ProviderVersion=acc"
=== RUN   TestAccAzureRMMonitorMetricAlert_multiScope
=== PAUSE TestAccAzureRMMonitorMetricAlert_multiScope
=== CONT  TestAccAzureRMMonitorMetricAlert_multiScope
--- PASS: TestAccAzureRMMonitorMetricAlert_multiScope (1060.25s)
PASS
ok      github.com/terraform-providers/terraform-provider-azurerm/azurerm/internal/services/monitor/tests       1060.277s

Copy link
Member

@tombuildsstuff tombuildsstuff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@magodo I've taken another look through and this mostly LGTM - if we can ensure all the fields are set then this otherwise LGTM 👍

"target_resource_type": {
Type: schema.TypeString,
Optional: true,
Computed: true,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be Computed?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, for the single scope of a certain resource, the target_resource_type will be deduced by service and returned in the response.

"target_resource_location": {
Type: schema.TypeString,
Optional: true,
Computed: true,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be Computed?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same reason as above.

return expandMonitorMetricAlertWebtestLocAvailCriteria(d.Get("webtest_location_availability_criteria").([]interface{})), nil
default:
// Guaranteed by schema `AtLeastOne` constraint
return nil, errors.New("unknwon criteria type")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
return nil, errors.New("unknwon criteria type")
return nil, fmt.Errorf("unknown criteria type")

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about this as there is no argument except the format string here.


return []interface{}{
map[string]interface{}{
"webtest_id": webtestID,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there's an existing resource for this with web_test - so it'd be worth making this consistent to be clearer

arguably this could make sense as application_insights_web_test_id rather than such a generic name?

website/docs/r/monitor_metric_alert.html.markdown Outdated Show resolved Hide resolved
website/docs/r/monitor_metric_alert.html.markdown Outdated Show resolved Hide resolved
website/docs/r/monitor_metric_alert.html.markdown Outdated Show resolved Hide resolved
@ghost ghost added size/XXL and removed size/XL labels Jul 15, 2020
@magodo
Copy link
Collaborator Author

magodo commented Jul 15, 2020

@tombuildsstuff I have updated some code per your comments and replied the other comments with justifications, please take a look!

@jackofallops
Copy link
Member

Tests passing:
image

@jackofallops jackofallops merged commit 1f316b3 into hashicorp:master Jul 16, 2020
jackofallops added a commit that referenced this pull request Jul 16, 2020
@ghost
Copy link

ghost commented Jul 16, 2020

This has been released in version 2.19.0 of the provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. As an example:

provider "azurerm" {
    version = "~> 2.19.0"
}
# ... other configuration ...

@AdamCoulterOz
Copy link
Contributor

thanks @jackofallops appreciate this! :-D

katbyte pushed a commit that referenced this pull request Aug 11, 2020
…tiMetricCriteria for legacy metric alerts (#7995)

The change in #7159 deprecates the usage of SingleResourceMultiMetricCriteria outright (replaced by MultipleResourceMultipleMetricCriteria). Unfortunately, that breaks the users who have metric alert created before that PR merged, which was using SingleResourceMultiMetricCriteria as its type. Then once those metric alerts get updated, current code will trigger an update from SingleResourceMultiMetricCriteria to MultipleResourceMultipleMetricCriteria, which seems not supported by service (as reported in #7910).

This PR keeps those legacy resource to use the SingleResourceMultiMetricCriteria. If user wants to use the MultipleResourceMultipleMetricCriteria, they will have to recreate the resource.

(fixes #7910)
@ghost
Copy link

ghost commented Aug 15, 2020

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 👉 hashibot-feedback@hashicorp.com. Thanks!

@hashicorp hashicorp locked and limited conversation to collaborators Aug 15, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support of dynamic alerts
7 participants