-
Notifications
You must be signed in to change notification settings - Fork 63
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
Enforce tenant labels on rule storage PUT request #219
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cool! 📐 I think after we merge #198 we'd need to update the tests for the write cases too
var rawRules rules.Rules | ||
if err := yaml.Unmarshal(body, &rawRules); err != nil { | ||
level.Error(rh.logger).Log("msg", "could not unmarshal rules", "err", err.Error()) | ||
http.Error(w, "error unmarshaling rules", http.StatusInternalServerError) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
http.Error(w, "error unmarshaling rules", http.StatusInternalServerError) | |
http.Error(w, "error unmarshalling rules", http.StatusInternalServerError) |
api/metrics/v1/rules.go
Outdated
|
||
body, err = yaml.Marshal(rawRules) | ||
if err != nil { | ||
level.Error(rh.logger).Log("msg", "could not marshal YAML", "err", err.Error()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
level.Error(rh.logger).Log("msg", "could not marshal YAML", "err", err.Error()) | |
level.Error(rh.logger).Log("msg", "could not marshal rules YAML", "err", err.Error()) |
api/metrics/v1/rules.go
Outdated
body, err = yaml.Marshal(rawRules) | ||
if err != nil { | ||
level.Error(rh.logger).Log("msg", "could not marshal YAML", "err", err.Error()) | ||
http.Error(w, "error marshaling YAML", http.StatusInternalServerError) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
http.Error(w, "error marshaling YAML", http.StatusInternalServerError) | |
http.Error(w, "error marshaling rules YAML", http.StatusInternalServerError) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think since we have the same marshaling logic also in the get
method maybe we could extract this to a separate function and reuse it in both get/put endpoints? same for the auth logic
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think we can do it for both marshaling and unmarshalling rules!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good and great PR description @saswatamcode! Few questions, mostly just curious 😁
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nothing more to add 🥳
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just one comment on continuing to enforce on read path
Signed-off-by: Saswata Mukherjee <saswataminsta@yahoo.com>
Signed-off-by: Saswata Mukherjee <saswataminsta@yahoo.com>
Signed-off-by: Saswata Mukherjee <saswataminsta@yahoo.com>
Let me also update this with the test cases from #198. |
Signed-off-by: Saswata Mukherjee <saswataminsta@yahoo.com>
618ab5b
to
3f7eaac
Compare
Signed-off-by: Saswata Mukherjee <saswataminsta@yahoo.com>
Signed-off-by: Saswata Mukherjee <saswataminsta@yahoo.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @saswatamcode
Currently, we enforce tenant labels on rules by adding the labels to them when Observatorium API gets it from the rules storage client i.e, the rules will only have the tenant labels when we get it from the API
rules/raw
endpoint.With the recent changes in thanos-rule-syncer and rules-objstore, this means,
listallrules
endpoint, thanos-rule-syncer will try to get all rules by hitting rules-objstore directly (so enforcing labels won’t work as we’re no longer relying on the API read path, but read from rules-objstore directly)This PR fixes the above issue, by ensuring that the API adds tenant labels while making the PUT request to the rules storage client and validating the labels when a GET request is made. This way tenant labels are propagated to the rules storage client and then eventually to thanos-rule-syncer and Thanos Ruler.
For more diagrammatic context see MON-2169.