-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
operator: Ruler enhancement proposal #5985
Conversation
a67c095
to
252d62f
Compare
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 for putting the design document together. I think this is mostly LGTM.
I would like to see a more flexible mapping of Rules to Stacks, but that is not a hard requirement for merging.
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.
LGTM! Great work. For my taste, there are too many CR details discussed here that might be discussed in PR.
I think I would vote for fewer API components and have LokiRule for a start - no need to confuse people and break consistency here. Similar as it was done in PromRule.
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.
Left a few small suggestions, but overall looks reasonable to me.
|
||
## Drawbacks | ||
|
||
The above proposed design and implementation for LokiStack Ruler support adds a significant amount of new APIs as well as complexity into exposing a declarative approach **only** for the ruler component. Regardless the hard effort to minimize the amount of configuration settings in the proposed CRDs it remains still a huge addition to the operator code base. In contrast to the existing `LokiStack` CRD that is a very slim set of Loki settings (Note: without considering the gateway tenant configuration), the `RulerConfig` is almost one-to-one identical to the [ruler config](https://grafana.com/docs/loki/latest/configuration/#ruler). |
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 would consider slimming down some of these specs and instead use reasonable defaults until the need for such complexity is proven. This would reduce the new surface area by a large margin and options could be added incrementally as needed.
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.
@owen-d From a user experience perspective the amount of non-defaulted fields the user needs to declare thanks to +kubebuilder:default
annotation is limited to a minimum. Do you foresee any upcoming changes for remote_write
or alertmanager
(e.g. fields that will be deprecated, removed or replaced)?
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 don't see any changes coming, but @dannykopping may have a better sense than I.
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.
A few more comments. Sorry for forgetting to click the send button last week.
c6a0fbc
to
b355057
Compare
What this PR does / why we need it:
The following PR adds a enhancement proposal for adding Ruler support into the Loki Operator.
Which issue(s) this PR fixes:
Addresses #5211 and #5843
Special notes for your reviewer:
Checklist
CHANGELOG.md
.docs/sources/upgrading/_index.md