prometheus-operator / kube-prometheus

Use Prometheus to monitor Kubernetes and applications running on Kubernetes
https://prometheus-operator.dev/
Apache License 2.0
6.73k stars 1.93k forks source link

Change jsonnet directory layout #874

Closed paulfantom closed 3 years ago

paulfantom commented 3 years ago

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

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

Sounds good to me, lets document that!

paulfantom commented 3 years ago

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 commented 3 years ago

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