Allow ability to specify Grafana image version/tag in the Grafana CustomResourceDefinition

[robbieheywood]

Lots of other operators allow the ability to specify the base image used for the resource in the CustomResourceDefinition. We've found this to be really useful, as we can upgrade/patch the image without also having to also change/upgrade the operator.

For the grafana-operator, we could add a version/tag/image field to the Grafana CustomResourceDefinition to allow doing this. Is this something you'd consider doing / accepting a PR for?

Couple of examples from other operators:

• Prometheus Operator (see baseImage in https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#prometheusspec)]
• Elastic Operator (see 'version' field in https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-quickstart.html#k8s-deploy-elasticsearch)

[pb82]

You can currently override the Grafana image using a flag: https://github.com/integr8ly/grafana-operator/blob/master/documentation/deploy_grafana.md#operator-flags

[robbieheywood]

Sure, you can override in the grafana-operator, but I was hoping ideally for a way on specifying this on the actual Grafana resource. This allows you to e.g. upgrade between different Grafana versions easily (because you can run two different versions of Grafana at the same time). At the moment, to update Grafana version, you have to rollout a new version of the grafana-operator and there's no way of running more than one version at a time.

[david-martin]

• Prometheus Operator (see baseImage in [https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#prometheusspec)]](https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#prometheusspec)%5D)
• Elastic Operator (see 'version' field in https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-quickstart.html#k8s-deploy-elasticsearch)

@robbieheywood That's interesting. One reason I've been reluctant to add support for specifying images is to ensure upgrading between different versions is more controlled. If the operand image can be changed by the user, then it makes it difficult for the operator to give any guarantees of supportability with different versions of the operand, particularly upgrading between 2 versions that would require some changes. Specifying a different image version/tag that what was tested would probably be fine for minor or patch differences (with no future support guarantee), but definitely needs some thought about different major version support.

[robbieheywood]

Thanks for taking the time to reply @david-martin! By allowing the operand image version to be specified as an argument for the operator, doesn't the operator already need to support different versions?

[david-martin]

By allowing the operand image version to be specified as an argument for the operator, doesn't the operator already need to support different versions

I guess you're right. I think we made a concession when hit with the problem of having upstream & downstream (community vs. productised) image support. @pb82 Do you recall how that conversation went and what was agreed?

I'm starting to wonder if we might be putting the cart before the horse in terms of imposing restrictions before we know of specific restrictions that are needed to prevent problems.

[pb82]

@david-martin I think we decided to allow overriding the image so that we can use the productized image for our purposes, while still defaulting to the Grafana community image upstream (which is more suitable there).

[nobody4t]

@pb82 This makes more sense. Which kind of format will be preferred, image:tag or image@shaxxxxx? Or should we have both. Currently we use the hash and ocp also use this kind too.

[hubeadmin]

@robbieheywood the requested feature has been implemented by @dongwangdw and merged to master, thanks for contributing 👍