Add new_group_delay monitor option #1176
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
chrismdd
force-pushed
the
chrism/add-new_group_delay-monitor-option
branch
2 times, most recently
from
bdbe643 to
4c0eb74
Compare
zippolyte
previously approved these changes
Aug 19, 2021
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
zippolyte
force-pushed
the
chrism/add-new_group_delay-monitor-option
branch
from
ddc4f82 to
c784f2b
Compare
|
/azp run |
zippolyte
approved these changes
Aug 20, 2021
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
This change does not appear to work as a replacement for new_host_delay; we see an error |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds a new monitor option,
new_group_delayto the monitor data source and resource.new_group_delayis a replacement fornew_host_delaythat works for all multi-alert monitors, not only for those grouped by host. When both options are specified in a monitor definition,new_group_delayoverridesnew_host_delay.new_host_delaycurrently defaults to 300 in this provider. Removing this default would be a breaking change and is therefore not possible without a major version update.The ideal behavior would be for
new_group_delayandnew_host_delayto conflict with each other, and for the provider to not set a default value fornew_host_delaywhennew_group_delayis specified in the config of a monitor resource. Unfortunately, due to limitations of the terraform SDK, it is not possible (as far as I can tell) to reliably distinguish betweennew_group_delaybeing set to zero in the config and not being set at all. Specifically, I found that it wasn't possible to unset this field inupdateMonitorStatebecauseResourceDatastores fields in multiple levels that are merged when reading the field, but we can only unset the field at one level.Instead, we opted to keep
new_group_delayandnew_host_delayindependent. This has the downside that disabling delay for monitors grouped by by host requires settingnew_host_delayto zero, despite the field now being deprecated. This requirement is clearly documented.Fixes #1183