Generate random namespace id

[domtes-form3]

When rules namespace resources are created they get assigned an hash of the namespace attribute as internal ID.
This leads to clashes when provisioning multiple rule groups within the same namespace.

• internally, this ID is not managed to fetch or delete the resource (the namespace attribute is used instead)
• the generated random ID strings are 64 bytes long to keep the same length, just in case

Pending PR against upstream project: ovh#25

[nijave]

I think the original design was for a single mimirtool_ruler_namespace resource to have complete control over everything in the namespace.

Do you have an example of the Terraform config that is causing an issue?

[domtes-form3]

It's possible that I'm hitting a corner case, as I'm migrating some alerts provisioned in the following way:

resource "mimirtool_ruler_namespace" "demo1" {
  namespace  = "demo"
  config_yaml = file("rules1.yaml")
}

resource "mimirtool_ruler_namespace" "demo2" {
  namespace = "demo"
  config_yaml = file("rules2.yaml")
}

The actual rules are irrelevant in this context.
The terraform code gets validated correctly, and on creation it's possible to see how resources are created but assigned the same ID.

This is how the rules look in grafana:

Planning again will show a diff

and deleting the resources will fail

[nijave]

I’ve been using Datadog for the last 5 months so I’m a little rusty on how this works. Iirc this assumes control over the entire namespace and is a wrapper around the go API used here https://grafana.com/docs/mimir/latest/manage/tools/mimirtool/#load-rule-group. I think it should be possible to make a rule_group resource that filters down and does whatever mimirtool is doing.

I think additional changes are needed since the diff logic is still built around the namespace so you’ll get two Terraform resources competing for control of the mimir resource.

Terraform has some yaml functions that can combine multiple files. You could also “stage” the data on S3 or some object storage then have Terraform pull down and merge all the files before using the namespace mimir resource (however this depends on your use case).

Where I worked before, we ran Terraform inside Kubernetes with Weaveworks tf-controller. This allows you to store rule definitions in ConfigMaps then Terraform can data source across namespaces, do any merging, and provision.

[nijave]

I think additional changes are needed since the diff logic is still built around the namespace so you’ll get two Terraform resources competing for control of the mimir resource.

Given that, I'm going to close this but feel free to re-open if you still need it and find a way to work around that issue