sloth
sloth copied to clipboard
slok
Spec Format Varies
The spec for an SLO in a Kubernetes resource varies from the spec fed directly to the binary. By unifying these, users could easily test against the binary to ensure that the output works as they expect and then insert it into the custom resource. Would it be possible to do that unification?
Hi @isugimpy!
Thanks for the issue, At the beginning they were the same, I did it on purpose the change on the CRD to follow Kubernetes de-facto standards (camelCase instead of snake_case), because the prometheus/v1 spec was already using snake_case.
However the CLI accepts the CRD too, so you can generate the Prometheus-operator Rules crd using the binary CLI on demand if you want to use it on CI.
On the next release I plan to add a validate command so it can be used in CI and the feedback loop is faster than waiting to deploy it on a Kubernetes cluster (in case you are using the k8s controller).
Does this solve your use case? If not, I think that we should think asking the users (you included), if creating a prometheus/v2 spec would make sense and use CamelCalse
I think it could potentially solve my case, yes! I actually didn't realize the CLI accepted the CRD, apparently I missed that in my reading of the readme last night. Personally, I think it'd be great if the prometheus/v2 spec happened, but that's maybe not necessary at this stage. Might be better to stick with prometheus/v1 for now just to give you an opportunity to collect more info about how people are using this in a run-up to an eventual 1.0 release, and then do prometheus/v2 using that collected knowledge to coincide with 1.0.
Awesome! Indeed you are right! this feedback is pure gold :) So many thanks.
I'll take into account for future releases (and ask these same things to other people too), if you have other types of feedback (good or bad) I would appreciate it a lot!
Once again many thanks!