-
Notifications
You must be signed in to change notification settings - Fork 167
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
Recording rules duplicates check #493
Comments
r3code
added a commit
to r3code/sloth
that referenced
this issue
Apr 4, 2023
r3code
added a commit
to r3code/sloth
that referenced
this issue
Apr 4, 2023
This was referenced Apr 4, 2023
r3code
added a commit
to r3code/sloth
that referenced
this issue
Apr 5, 2023
r3code
added a commit
to r3code/sloth
that referenced
this issue
Apr 5, 2023
r3code
added a commit
to vseinstrumentiru/sloth
that referenced
this issue
Apr 5, 2023
r3code
added a commit
to r3code/sloth
that referenced
this issue
Apr 10, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've noticed that if I pass a folder to
sloth validate
it allows SLO duplicates to exist.When creating a new SLO sometemes I copy spec from existing specs and forgot to change names.
Sloth perfectly validates and generates rules in such cases. But it can lead to duplicates of recording rules, and unpredictable behaviour durind recording.
We can deploy rules as prom, k8s, and openslo. Prom and K8S are almost the same and have equal slo_id format
<service>-<slo.name>
, but OpenSLO uses slightly different<service>-<slo.name>-<seq_no>
.So it looks like better not to mix spec types for the same service.
But if I have a folder with specs of one type, e.g. Prom specs for CLI generation, I want to know about slo duplicates in a folder or multifile yml.
The text was updated successfully, but these errors were encountered: