Kube-prometheus: Change jsonnet directory layout

[paulfantom]

What is missing?
Good user experience.

Why do we need it?
To improve user experience by categorizing various jsonnet snippets to create a clear picture.

Environment

• kube-prometheus version:

  post release-0.7

Anything else we need to know?:

This is building on top of https://github.com/prometheus-operator/kube-prometheus/pull/873

I would like to categorize files in jsonnet/kube-prometheus directory in a following pattern:

.
├── jsonnetfile.json
├── main.libsonnet # previously kube-prometheus.libsonnet
├── components/  # holding major components of the stack
│   ├── mixin/
│   │   ├── alerts
│   │   │   ├── alerts.libsonnet
│   │   │   ├── general.libsonnet
│   │   │   ├── node.libsonnet
│   │   │   └── tests.yaml
│   │   ├── custom.libsonnet
│   │   ├── kubernetes.libsonnet
│   │   └── rules
│   │       ├── general.libsonnet
│   │       ├── node-rules.libsonnet
│   │       └── rules.libsonnet
│   ├── alertmanager.libsonnet
│   ├── blackbox-exporter.libsonnet
│   ├── grafana.libsonnet
│   ├── ksm-autoscaler.libsonnet
│   ├── kube-state-metrics.libsonnet
│   ├── kube-rbac-proxy.libsonnet
│   ├── node-exporter.libsonnet
│   ├── prometheus.libsonnet
│   ├── prometheus-adapter.libsonnet
│   └── prometheus-operator.libsonnet
├── addons/  # various snippets that can be applied separatelly
│   ├── dropping-deprecated-metrics-relabelings.libsonnet
│   ├── grafana-weave-net-cluster.json
│   ├── grafana-weave-net.json
│   ├── kube-prometheus-all-namespaces.libsonnet
│   ├── kube-prometheus-anti-affinity.libsonnet
│   ├── kube-prometheus-bootkube.libsonnet
│   ├── kube-prometheus-config-mixins.libsonnet
│   ├── kube-prometheus-custom-metrics.libsonnet
│   ├── kube-prometheus-external-metrics.libsonnet
│   ├── kube-prometheus-insecure-kubelet.libsonnet
│   ├── kube-prometheus-ksonnet.libsonnet
│   ├── kube-prometheus-managed-cluster.libsonnet
│   ├── kube-prometheus-node-ports.libsonnet
│   ├── kube-prometheus-static-etcd.libsonnet
│   ├── kube-prometheus-strip-limits.libsonnet
│   ├── kube-prometheus-thanos-sidecar.libsonnet
│   └── kube-prometheus-weave-net.libsonnet
└── platforms/  # Ready to apply examples for each platform.
    ├── kube-prometheus-eks.libsonnet
    ├── kube-prometheus-gke.libsonnet
    ├── kube-prometheus-kops-coredns.libsonnet
    ├── kube-prometheus-kops.libsonnet
    ├── kube-prometheus-kubeadm.libsonnet
    ├── kube-prometheus-kube-aws.libsonnet
    └── kube-prometheus-kubespray.libsonnet

RFC @prometheus-operator/kube-prometheus-reviewers

[brancz]

I'd say for addons and platforms we can drop the kube-prometheus- prefix now. Otherwise :+1:

One day I would still like to see something a little more ergonomic (definitely my own perception, maybe for others it's not more ergonomic) like:

kp + 
  kp.platforms.gke +
  kp.addons.allNamespaces

That's just food for thought though, and is not mutually exclusive with your proposal, so from my side, feel free to move ahead with your proposal.

[lilic]

One thing:
I seen a good suggestion from Thor that the mixin name is confusing. Maybe we can rename that at least here to something else? Also because we have mixins in other subdirs per the chart above.

Otherwise this makes sense to me!

[brancz]

An additional general statement .. as the "API" of kube-prometheus as a library is essentially the main.jsonnet, I think we can feel free to refactor within components/ however we want.

It would be nice if we could write this "contract" down in the readme.

[brancz]

@lilic I feel we should wait until we find a new name within the community before renaming things here. I feel right now this would be a bit premature and we'd risk that we have to change it multiple times .. As I mentioned in my previous comment, anything within components/ we're pretty free to refactor at any point in time (I guess that's also an argument against my point haha).

[lilic]

Sounds good to me, lets document that!

[paulfantom]

It would be nice if we could write this "contract" down in the readme.

I agree and will write it in one of PRs with docs update.

As for renaming mixin/ directory - I also don't like it, but I didn't have any other good name. I am open to proposals on the name.

[lilic]

I would say we open a separate issue and we can discuss on the naming :D