We want to move kube-prometheus into its own repository (again). Here is why:
Two years ago kube-prometheus was moved from its own repository into the Prometheus Operator repository to keep both projects more synchronized, as the right tools were missing. A lot of people are confused that kube-prometheus is inside the Prometheus Operator repository and we sometimes confuse things too.
The most significant drawback of having kube-prometheus inside the Prometheus Operator repository, is the fact that we cannot version kube-prometheus. All tagged releases are for the Prometheus Operator and kube-prometheus itself has no releases. If necessary, we would really like to be able to backport fixes to older kube-prometheus versions.
In the meantime, we moved kube-prometheus to a jsonnet based stack. All Kubernetes manifests are generated using ksonnet-lib and we worked on Prometheus alerts & rules and Grafana dashboards specifically for Kubernetes with the upstream community in the kubernetes-mixin, and other mixins like the etcd-mixin.
The last missing piece was to have something like a package manager for those jsonnet mixins, that we could more easily assemble what we needed. Hence, jsonnet-bundler was born.
Especially jsonnet-bundler allows us to overcome the drawbacks that we had two years ago. As a quick and easy solution, we think of moving kube-prometheus back into coreos/kube-prometheus.
We want to split the contrib/kube-prometheus folder out of the Prometheus Operator repository and merge its history with the old kube-prometheus repository. All current issues and PRs on coreos/kube-prometheus are closed.
Once we move kube-prometheus, we can finally start doing releases. The YAML manifests could be generated in the CI and contributors don't need to re-generate after each jsonnet change.
What do you think @ant31 @mxinden @paulfantom @squat @s-urbaniak @sichvoge @brancz
I would very much like to see this happen :+1: . I think the only open question is which repository _exactly_. I would say because the dependency management process is so easy, for now we transfer it back to the coreos/kube-prometheus repository and should we decide to put it under another governance we can still do that, but can get started on removing the pain we have due to this _now_.
agreed :+1:
SGTM. We've talked about this exact plan for a few months, and now is a good time.
Most helpful comment
I would very much like to see this happen :+1: . I think the only open question is which repository _exactly_. I would say because the dependency management process is so easy, for now we transfer it back to the
coreos/kube-prometheusrepository and should we decide to put it under another governance we can still do that, but can get started on removing the pain we have due to this _now_.