johnride
  • Joined on 2024-02-06
johnride deleted branch feat/dryRun from NationTech/harmony 2025-06-26 15:14:56 +00:00
johnride pushed to master at NationTech/harmony 2025-06-26 15:14:37 +00:00
55143dcad4 Merge pull request 'feat: add dry-run functionality and similar dependency' (#62) from feat/dryRun into master
acfb93f1a2 feat: add dry-run functionality and similar dependency
Compare 2 commits »
johnride merged pull request NationTech/harmony#62 2025-06-26 15:14:31 +00:00
feat: add dry-run functionality and similar dependency
johnride suggested changes for NationTech/harmony#66 2025-06-26 14:05:44 +00:00
feat: add service monitors support to prom

The good :

johnride commented on pull request NationTech/harmony#66 2025-06-26 14:05:44 +00:00
feat: add service monitors support to prom

That is inconvenient to use. Should be much shorter with something like :

johnride commented on pull request NationTech/harmony#66 2025-06-26 14:05:43 +00:00
feat: add service monitors support to prom

I guess operator is not any string? Probably should be an enum too.

johnride commented on pull request NationTech/harmony#66 2025-06-26 14:05:43 +00:00
feat: add service monitors support to prom

I think we already do have a Label type somewhere. I think it would be more appropriate here than String. That's true for all the label related fields in this file.

johnride commented on pull request NationTech/harmony#66 2025-06-26 14:05:42 +00:00
feat: add service monitors support to prom

Not a String, should be a path type of some sort. I think we already handle this somewhere else correctly.

johnride commented on pull request NationTech/harmony#66 2025-06-26 14:05:42 +00:00
feat: add service monitors support to prom

This should be an enum :

johnride commented on pull request NationTech/harmony#66 2025-06-26 14:05:42 +00:00
feat: add service monitors support to prom

This should be a specific type that validates the path

johnride commented on pull request NationTech/harmony#66 2025-06-26 13:49:07 +00:00
feat: add service monitors support to prom

Yeah ok, I see what you did there.

But this is not a good use case for Macros. Macros are a last resort when the type semantics are already correct and we can't rely on the regular rust type…

johnride commented on pull request NationTech/harmony#66 2025-06-26 13:30:05 +00:00
feat: add service monitors support to prom

OK that makes sense. Why not implement Display? I guess the format is not the expected one?

Also this file really deserves some tests to make sure the config output is correct.

johnride released Latest Snapshot at NationTech/harmony 2025-06-26 13:18:32 +00:00
johnride commented on pull request NationTech/harmony#66 2025-06-25 19:40:00 +00:00
feat: add service monitors support to prom

What's the use case for this? I don't see this used in this pr.

johnride commented on pull request NationTech/harmony#66 2025-06-25 19:40:00 +00:00
feat: add service monitors support to prom

Why not use the same pattern as the rest of the file?

johnride suggested changes for NationTech/harmony#67 2025-06-25 19:31:58 +00:00
feat: added alert rule and impl for prometheus as well as a few preconfigured bmc alerts for dell server that are used in the monitoring example

Looks pretty good overall. Some minor refactoring comments but the rest is great!

johnride commented on pull request NationTech/harmony#67 2025-06-25 19:31:58 +00:00
feat: added alert rule and impl for prometheus as well as a few preconfigured bmc alerts for dell server that are used in the monitoring example

For clarity, this is fine-ish to be in the kube_prometheus mod because it is specifically for pvc alerts but I think alert definitions should be in another module called just prometheus. kube_prometheus is for stuff specific to deploying prometheus on k8s. It is very possible to have a prometheus deployed somewhere else (AWS managed or grafana cloud maybe) which scrapes k8s targets and will want this alert.

johnride released Latest Snapshot at NationTech/harmony 2025-06-25 15:17:45 +00:00