You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
I would very much like to see this happen 👍 . 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.
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
The text was updated successfully, but these errors were encountered: