grafana_rule_group rule block ordering reassigns rule UIDs

[JacobsonMT]

Terraform Version

1.10.0

Terraform Grafana Provider Version

3.13.1

Grafana Version

main (11.4.0-pre)

Affected Resource(s)

• grafana_rule_group

Terraform Configuration Files

resource "grafana_rule_group" "rule_group_527ddb6599bf18b3" {
  name             = "1m"
  folder_uid       = grafana_folder.my_folder.uid
  interval_seconds = 60

  rule {
    name      = "example alert"
    is_paused = true
    condition = "A"
    data {
      ref_id = "A"
      datasource_uid = "__expr__"
      relative_time_range {
        from = 600
        to   = 0
      }
      model = "{}"
    }
  }
  rule {
    name      = "example alert 2"
    is_paused = true
    condition = "B"
    data {
      ref_id = "B"
      datasource_uid = "__expr__"
      relative_time_range {
        from = 600
        to   = 0
      }
      model = "{}"
    }
  }
}

Expected Behavior

Modifications to a grafana_rule_group that alter the ordering of rules would preferably retain the connection between a rule and its computed UID. This may be difficult to do in general given how alert rules are not resources and are instead modelled as LIST type blocks under a group. So, at the very least the following should hold true:

• Modifications to alert rule ordering should not unintentionally allow a rule to obtain the UID of an existing rule.
• There should be a way to (at least optionally) ensure a rule definition does not change UIDs when rules are reordered.

Actual Behavior

Modifying rule ordering in a group can unintentionally reassign a rule's UID to that of a different rule in the group. There are multiple ways this can happen, some examples:

• Deleting a rule in the middle of a group: will reassign the UID all rules that follow it to that of the rule in it's idx-1
• Adding a rule in the middle of a group: will give the new rule the UID of the previous rule at that index and reassign all following rules to that of the rule in it's idx+1. The last rule will obtain a newly generated UID.
• Swapping two rules: will swap their UIDs.

Steps to Reproduce

1. Apply the above provided state.
2. Note the UIDs of the created rules.
3. Delete the example alert block.
4. Apply
5. Note that example alert 2 rule now has the UID of the deleted example alert rule.

Important Factoids

Not sure how likely a general solution not requiring modifications to existing HCL is, considering this is tied pretty closely to how Alert rules and groups are modelled. That being said, optionally allowing a rule block UID to be configurable is a simple backwards compatible change and should allow a workaround to the issue.

References

No response

[moustafab]

I've been digging into this one and it's a bit complex. One way I think we might be able to get around it is by implementing a CustomDiff function which calculates some kind of semantic difference. It'd be somewhat arbitrary what constitutes a "new" rule rather than an edit of an existing one though as there isn't really anything that necessarily indicates identity from the configuration. I was thinking roughly in the direction of Levenshtien/edit distances or maybe weighting the various keys differently. (i.e. Title change means it's new rule, modifications of the expression not so much?)

I think perhaps if the basic semantics of reordering rules doesn't maintain the UID and we err on the side of creating new UIDs rather than unintentional rewriting of existing rules that might be sufficient.

[moustafab]

Discussed with @yuri-tceretian and we resolved to link the uid to the rule title, meaning if the title is changed we'll ensure that we get a new uid. Additionally we're going to try to make the uid a configurable field on the terraform resource similar to other mechanisms of provisioning. The user will be responsible for ensuring the global uniqueness if the uid is explicitly specified in the terraform.

[moustafab]

Unfortunately it seems that implementing a CustomDiff function is not possible with non-Computed fields (which rule is). This means that we cannot modify the plan for rule differences and because the rules are part of a TypeList on a parent resource rule_group a ForceNew ends up forcing a new rule-group altogether.

WRT making uid Optional (i.e. user settable) this becomes a bit of a clunky footgun because there is no way to add validation to force the user to specify uid for ALL of the rule blocks if they specify it for any one. This means that if I set a uid for one rule and then reorder them then we can only indicate this to the user at Update time. This may be a somewhat acceptable path forward.