Prometheus-operator: Move kube-prometheus into its own separate repository

Created on 11 Apr 2019  路  3Comments  路  Source: prometheus-operator/prometheus-operator

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

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-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_.

All 3 comments

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.

Was this page helpful?
0 / 5 - 0 ratings