cert-manager example (community hack session) #21
Conversation
|
Will continue work on this on Friday |
| } | ||
|
|
||
| prometheusAlerts: v0: { | ||
| CertManagerCertExpirySoon: { |
There was a problem hiding this comment.
Maps! YISSSS! 🎉 🎉
Finally I will be able to stop iterating over the whole thing just to select one alert ^^
We'll need that tool (or good, documented examples) as part of polly org if we want to have widespread adoption. |
| // | ||
| // That's the ideal, anyway - we'll have to see what we can actually | ||
| // accomplish :) | ||
| dashboard_url: header.params.grafanaExternalUrl + "/d/TvuRo2iMk/cert-manager", |
There was a problem hiding this comment.
set a UID on your dashboard and you can get rid of that randomised string: TvuRo2iMk
Absolutely. I think the target here is probably docs + CUE helpers (i'm imagining more things in the "util" vein described over here) + impl in some tools. I think the helpers will probably be most useful. Any translation layer that exists must necessarily start by consuming a pop, which likely means starting from the [Go] CUE SDK, where it will be possible to rely on these helpers directly. That means the option will always be there to have the alerts/rules arrive in the userspace for that tool (e.g. HCL for terraform, jsonnet files for jsonnet) in the canonical Prometheus form of a list. It may not be the best option for users, but having the CUE util bit should make it available, in a standard way, for any consuming toolchain, and the author of that consumer gets to make their own UX judgment. |
Co-authored-by: malcolmholmes <[email protected]>
sdboyer
force-pushed
the
hacksession-certmanager
branch
2 times, most recently
from
a6bdcaf
to
9b0a42f
Compare
sdboyer
force-pushed
the
hacksession-certmanager
branch
from
9b0a42f
to
a555199
Compare
|
OK, this is ready to go. All the alerts and the grafana dashboard are there. Some notes:
|
This return naming pattern complies with the standard CUE approach to creating "functions."
| } | ||
| } | ||
|
|
||
| grafanaDashboards: v0: { |
There was a problem hiding this comment.
Minor issue - would it make sense to structure code in a similar way we did it in mixins?
put dashboards in separate files? With a pretty small pollypkg containing just 1 dashboard we already have a 1k+ LOC and it might get too long to be readable in case of larger pollypkgs/mixins.
There was a problem hiding this comment.
I think it would, yes.
we discussed this a bit on the last hack session - file layout relates heavily to how we namespace (URI) and generate code from a UI. The rules here can be simple, I think - handwaving, but basically:
- All pop files must be in the same directory
- All files must be in the same CUE package (unclear if we specify what that package must be)
- The emit value of the package must be an instance of
PollyPackage - Files created by UI-driven tools should follow some suffix or prefix pattern
- Files containing only some particular object type should follow some prefix or suffix pattern (we can lint this! 🎉)
There was a problem hiding this comment.
These rules have the effect of making package generation and linting pretty straightforward (standard CUE rules for loading a whole dir's package), removing any (I think?) unnecessary choice, render any within-the-pop importing unnecessary (unlike today's mixins). It should all be smooth and clear.
If you could post an issue about this, I'll use the next example/hack session as an opportunity to either do a new pop that conforms to these patterns, or make a new one 😄
Started working on converting this cert-manager mixin in a community hack session. Thanks to @rgeyer for his great questions!
Only got to one alert and a bunch of discussion around it, but that's OK!
Interesting possible change in here, though - this changes the structure of
PollyPackageto make rules and alerts more addressable from the outside. That is, instead of having a list, they're effectively all in a string-keyed map.This is an approach to the grouping problem i described to in #16. It does mean consuming tools will need to transform the alerts and rules in order to get them in the list form that Prom expects to see them - but i think that's acceptable. Thoughts, @metalmatze?
/cc @malcolmholmes - i know you wanted to map-ify these lists long, long ago