Do not upgrade Redpanda unless the user explicitly sets `image.tag`

[JakeSCahill]

What would you like to be added?

Unless the user provides an explicit override for image.tag use the existing image.tag in the user's existing values.

We could implement pre-upgrade hooks in the Helm chart that set the image.tag to the currently deployed Redpanda version if the image.tag value is not explicitly overridden.

Why is this needed?

Users performing a Helm upgrade without monitoring the Redpanda version might unintentionally deploy an incompatible Redpanda version.

The core team is working on a fix so that Redpanda does not allow you to break our upgrade compatibility rules: https://github.com/redpanda-data/core-internal/issues/1276

JIRA Link: K8S-182

[alejandroEsc]

I am not sure I understand the ask. If the user does not explicitly set the version we will always go with the default with the chart version. This is a problem if the user bumps to a chart version where the redpanda version has changed. I think we can help fix/adjust this issue with better release processes and policies. For example if we either append the release version of redpanda binary or we set a policy where the minor version bump must be done on each minor version change of the redpanda release we could mitigate these accidental upgrades. That would not always be 1-to-1 however, as minor chart version changes could also represent breaking changes to the chart itself as per today. However, we still have a more deterministic approach to version tying and it could also be more readily tracked.

That being said, a tool that can check upgrade compatibility before attempting upgrades would be nice. This could even exist in rpk or a standalone golang binary, and it could more easily fit in the operator itself.