Add ability to override indivual components versions

[lilic]

What is missing?

I would like the ability to upgrade just individual components version within releases.

Right now when you want to select a version of kube-prometheus you check the compatibility version matrix and go ahead and install a release based on which Kubernetes version you are running.

That works for most use cases, but sometimes upgrading Kubernetes versions is not possible, but you still want a newer version of prometheus operator.

Why do we need it?

Lets say a user is on Kubernetes version v1.24, so they have kube-prometheus release version pinned to release-0.12. Now lets say that user really wants a newer feature from prometheus operator, and in theory they don't have to upgrade Kubernetes versions as prometheus operator uses. But they can't upgrade to the version of kube-prometheus as the next one up is not compatable anymore with their Kubernetes version.

Having the ability for the user to override just individual component versions, like prom-operator would be super helpful. It doesn't need to be tested and should be up to the user to take the risk of this. But right now the only option is to fully rewrite kube-prometheus or fork it due to pinned versions in each release branch.

I can also see this being done for security reasons as another good option, for older non-supported versions of kube-prom.

Environment

Not applicable.

• kube-prometheus version:

Not applicable.

Anything else we need to know?:

👋 hi! 😄

[lilic]

cc @simonpasquier we already had a chat about this.

[lilic]

Also I believe we might need to do some things on https://github.com/jsonnet-bundler/jsonnet-bundler side of things. @metalmatze @brancz any thoughts and ideas how we could do that?

[brancz]

I don't think this really has anything to do with kube-prometheus. I think this should be solved in jsonnet-bundler. Currently jsonnet-bundler can only have a single version of a dependency, we should expand this to allowing to have multiple versions of the same dependency. It's honestly quite silly, because what you can do today already is fork whatever dependency you want a different version of at the version you want, install it, and use it to override.