Find a better name for the mixtool

[metalmatze]

Maybe we can find a better name for the mixtool.
Let's discuss.

@mxinden wants the name to better reflect the circumstances that this tool is mostly for monitoring related mixins (correct me if I'm wrong). Should we adapt to that? Maybe we can try to be open for contributions for non-monitoring related tasks / commands / objects?

Earlier in the project I named it locally jsonnet-mixer to match the naming of the jsonnet-bundler but having the jb and jm as command line tools, doesn't feel right.

Please always think about the name for the project itself, but also about how we could name it on the CLI.

/cc @brancz @s-urbaniak @squat @ant31

[ant31]

Is it a general tool or more dedicated to prometheus ?

NAME:
   mixtool generate - Generate files for Prometheus alerts & rules and Grafana dashboards as jsonnet mixin

USAGE:
   mixtool generate command [command options] [arguments...]

COMMANDS:
     grafana-dashboard  Generate a new file for a Grafana dashboard
     prometheus-alerts  Generate a new file for Prometheus alerts
     prometheus-rules   Generate a new file for Prometheus rules

OPTIONS:`

The name should reflect the scope of the project.
why not kube-prometheus ?

kube-prometheus deploy  # to be implemented
kube-prometheus generate  # to be implemented
kube-prometehus mixins prometheus-alerts 

[brancz]

No it’s not about kube Prometheus at all, it’s about monitoring mixins.

[ant31]

@brancz who are the targeted users ? Prometheus-operator ones ? prometheus one?
Does this tool has a usage outside the kubernetes scope ?
prom-mixin

[metalmatze]

This should be a valuable tool for people outside of Kubernetes, yes. It should be possible to use some mixins with alerts and by using the mixtool generate a valid configuration for running Prometheus on other platforms.
However, I think that we're pretty much coupled to Prometheus and Grafana. This can be extended to others though.

[brancz]

It's about authors and users of monitoring mixins, hence mixtool 🙂 . For us in particular it's any OpenShift component author, who has to write alerting rules (and dashboards, but for our use case alerting is more important), because we can automatically generate runbook documents from all possible components in OpenShift and provide the user/customer with an OpenShift branded experience. But more importantly it allows us to write monitoring mixins with the community (which has resulted in amazing alerting rules and dashboards in the kubernetes-mixin) and add the OpenShift bits just on top, giving us the best of both worlds: the ability to collaborate with the community, but also give users/customers the best and highest quality monitoring highly adapted to OpenShift.

[tombrk]

I must say mixtool is not too bad, because it reflects the aim of the project – tooling for mixins. Whether this means Jsonnet, Prometheus, whatever is really a question of what mixins are and this tool should adapt.

Currently mixins are written in Jsonnet and provide Prometheus and Grafana data, so this tool does exactly that.

To do less typing on the command line, it might make sense to rename the command to mix.

[brancz]

I kind of like mix

[metalmatze]

There's nothing wrong with the tool's name being mixtool and the binary being mix? I don't mind typing mixtool either though 😁

[brancz]

agreed