johnride
  • Joined on 2024-02-06
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 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: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: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: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 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 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

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

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 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
johnride deleted branch feat/publishComposer from NationTech/harmony 2025-06-25 15:14:52 +00:00
johnride pushed to master at NationTech/harmony 2025-06-25 15:14:49 +00:00
2c706225a1 feat: Publishing a release of harmony composer binary as latest-snapshot (#65)
johnride merged pull request NationTech/harmony#65 2025-06-25 15:14:49 +00:00
feat/publishComposer