A different Redpanda version is installed other than what is listed in `image.tag`

[vuldin]

I run the following command:

kubectl kustomize "https://github.com/redpanda-data/redpanda-operator/src/go/k8s/config/crd?ref=v2.1.12-23.3.3" | kubectl apply -f -
helm upgrade --install redpanda-controller operator --repo https://charts.redpanda.com/ -n redpanda --set image.tag=v2.1.12-23.3.3

And I eventually end up with a different Redpanda version:

# helm list -A
NAME                    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                           APP VERSION   
redpanda                redpanda        1               2024-02-21 04:48:49.00407281 +0000 UTC  deployed        redpanda-5.7.25                 v23.3.5       
redpanda-controller     redpanda        1               2024-02-21 04:47:46.30526161 +0000 UTC  deployed        operator-0.4.19                 v2.1.14-23.3.4

It turns out that the Redpanda version within the image.tag actually refers to the latest Redpanda version at the time of this release... but this isn't the version you are guaranteed to get.

JIRA Link: K8S-221

[chrisseto]

That kinda makes sense to me. There's no version pinning anywhere across the operator or helm charts :/

How is the redpanda release getting installed btw? AFAIK the operator helm chart doesn't deploy a redpanda instance with it.

IMO we should 🪓 the redpanda version from the versioning scheme. It doesn't really make sense to bind a version of redpanda to a specific operator release especially when it's just deploying a version of the helm chart. WDYT?

[vuldin]

IMO we should 🪓 the redpanda version from the versioning scheme.

I think that would be a great solution that would avoid the confusion altogether.

[chrisseto]

@JakeSCahill how complicated of a docs change do you think removing the redpanda version from the operator's versioning would be? We could potentially re-publish some of the operator versions without the redpanda version as well for consistency.

[chrisseto]

cc @mattschumpert

[mattschumpert]

Can't we simply say in our docs that this number in the CRD 'ref' version is the 'latest' Redpanda version the Operator can support? That part makes sense to me (you this is the max Redpanda this thing is designed for). Is that not good enough @vuldin ?

That said, I agree if the IMAGE tag version is listed as the max supported RP version thats maybe a bit more confusing.

Also we probably at a minimum should not include the 3rd digit in this metadata indicating latest supported RP for that Operator. Whereas major version support often requires stuff in Operator, that precision makes it more confusing and likely inaccurate.

[vuldin]

Can't we simply say in our docs that this number in the CRD 'ref' version is the 'latest' Redpanda version the Operator can support?

The remaining issue is that it is just too confusing. The helm chart also has an image.tag which is used to set the Redpanda version, so we have to get people to understand that:

1. the operator image.tag lists the Redpanda version, but likely not the version you will get installed
2. both the operator and the helm chart have an image.tag
3. the operator actually wraps the helm chart
4. set the helm chart image.tag through the operator config by nesting the config in a convoluted way

This is just not straight forward and simple. Each point above invites questions.

[chrisseto]

Can't we simply say in our docs that this number in the CRD 'ref' version is the 'latest' Redpanda version the Operator can support?

I'd prefer if we didn't go that route. As Josh has noted, it's quite confusing to see two versions where you expect to see one. It also means that we'd have to push out new versions of the operator even if no changes are required to "support" new versions of redpanda.

@mattschumpert are there any reasons to keep the RP version suffix? From my view point it's a net loss to have a scheme like that.

[david-yu]

Closing out since Platform centric versioning is now implemented as of v25.1.1.-beta1