Enforce Labels on Returned Rules #191
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
Rules are either Recording Rules or Alerting Rules, but not both. This commit fixes this fact in the OpenAPI specification. Signed-off-by: Lucas Servén Marín <lserven@gmail.com>
squat
force-pushed
the
enforce_rules_labels
branch
from
16b16c7 to
589c6d7
Compare
onprem
reviewed
Nov 15, 2021
jessicalins
reviewed
Nov 15, 2021
squat
force-pushed
the
enforce_rules_labels
branch
2 times, most recently
from
f100a51 to
d4e5f41
Compare
Currently, when a group of rules is unmarshaled, the concrete type in Go
will never be a rules.RecordingRule or a rules.AlertingRule, although
those types are defined in the rules package. Instead those rules will
always be some map[string]interface{} type. This means that it's not
possible for users of the package to perform type assertions on the
rules that are fetched via the client, which is a serious annoyance for
anyone using the package.
This commit fixes this by providing a custom unmarshaling function.
Furthermore, in order to fix unmarshaling via both JSON and YAML, the
commit switches the YAML package to ghodss/yaml, which is a superset of
the current YAML package, go-yaml/yaml.
Signed-off-by: Lucas Servén Marín <lserven@gmail.com>
Signed-off-by: Lucas Servén Marín <lserven@gmail.com>
squat
force-pushed
the
enforce_rules_labels
branch
from
d4e5f41 to
d6fd21b
Compare
Currently, recording and alerting rules that are fetched from the new rules/raw API will not have any tenant label attached to them. This means that when the rules are configured on a Thanos Ruler, the time series that are generated will not have a tenant label on them. This is a big problem, because without this tenant label, the very tenant to whom the rules belong cannot query for the time series, making them in effect useless. This commit enforces that all rules returned by the rules/raw endpoint have a tenant_id label attached to them. Note: this is a distinct problem from ensuring that the rules written by a tenant are guaranteed to only include data from that tenant. Currently, the rules from a tenant can select data from any tenant. This is a distinct problem and should absolutely be tackled in a follow up. Signed-off-by: Lucas Servén Marín <lserven@gmail.com>
jessicalins
approved these changes
Nov 16, 2021
There was a problem hiding this comment.
awesome 🎉
I've created a ticket for the note you mentioned in the description of the PR, so we don't forget about it: https://issues.redhat.com/browse/MON-2063
jessicalins
pushed a commit
to jessicalins/api
that referenced
this pull request
Dec 6, 2021
* rules/spec.yaml: fix enum
Rules are either Recording Rules or Alerting Rules, but not both. This
commit fixes this fact in the OpenAPI specification.
Signed-off-by: Lucas Servén Marín <lserven@gmail.com>
* rules: add custom UnmarshalJSON function
Currently, when a group of rules is unmarshaled, the concrete type in Go
will never be a rules.RecordingRule or a rules.AlertingRule, although
those types are defined in the rules package. Instead those rules will
always be some map[string]interface{} type. This means that it's not
possible for users of the package to perform type assertions on the
rules that are fetched via the client, which is a serious annoyance for
anyone using the package.
This commit fixes this by providing a custom unmarshaling function.
Furthermore, in order to fix unmarshaling via both JSON and YAML, the
commit switches the YAML package to ghodss/yaml, which is a superset of
the current YAML package, go-yaml/yaml.
Signed-off-by: Lucas Servén Marín <lserven@gmail.com>
* rules/rules.go: regenerate
Signed-off-by: Lucas Servén Marín <lserven@gmail.com>
* api: enforce tenant on generated time series
Currently, recording and alerting rules that are fetched from the new
rules/raw API will not have any tenant label attached to them. This
means that when the rules are configured on a Thanos Ruler, the time
series that are generated will not have a tenant label on them. This is
a big problem, because without this tenant label, the very tenant to
whom the rules belong cannot query for the time series, making them in
effect useless. This commit enforces that all rules returned by the
rules/raw endpoint have a tenant_id label attached to them.
Note: this is a distinct problem from ensuring that the rules written by
a tenant are guaranteed to only include data from that tenant.
Currently, the rules from a tenant can select data from any tenant. This
is a distinct problem and should absolutely be tackled in a follow up.
Signed-off-by: Lucas Servén Marín <lserven@gmail.com>
Start e2e test
Signed-off-by: Jéssica Lins <jessicaalins@gmail.com>
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.
Currently, recording and alerting rules that are fetched from the new
rules/raw API will not have any tenant label attached to them. This
means that when the rules are configured on a Thanos Ruler, the time
series that are generated will not have a tenant label on them. This is
a big problem, because without this tenant label, the very tenant to
whom the rules belong cannot query for the time series, making them in
effect useless. This PR enforces that all rules returned by the
rules/raw endpoint have a tenant_id label attached to them.
Note: this is a distinct problem from ensuring that the rules written by
a tenant are guaranteed to only include data from that tenant.
Currently, the rules from a tenant can select data from any tenant. This
is a distinct problem and should absolutely be tackled in a follow up.
In order to be able to apply the labels, we must assert the type of the rules.
Currently, when a group of rules is unmarshaled, the concrete type in Go
will never be a rules.RecordingRule or a rules.AlertingRule, although
those types are defined in the rules package. Instead those rules will
always be some map[string]interface{} type. This means that it's not
possible for users of the package to perform type assertions on the
rules that are fetched via the client, which is a serious annoyance for
anyone using the package.
This PR also fixes this by providing a custom unmarshaling function.
Furthermore, in order to fix unmarshaling via both JSON and YAML, the
PR switches the YAML package to ghodss/yaml, which is a superset of
the current YAML package, go-yaml/yaml.
Finally, rules are either Recording Rules or Alerting Rules, but not both. This
PR fixes this fact in the OpenAPI specification.