Figure out versioning for the operator

[dtantsur]

The initial idea (I think I put that to the design proposal) was to couple IrSO versions with ironic-image versions. This makes sense from the good practices perspective (an operator installs a specific version of software and handles upgrades). But also, if we need to make point releases of IrSO specifically, the versions may start diverging.

[dtantsur]

Idea 1 (obvious): just let patch versions diverge. Ironic-image already does not match Ironic versions perfectly.

[tuminoid]

Deviating a little (idea 1) makes it super confusing for consumers. With versions very close to each other, it is very easy to think they're just oversights or typos and assume things based on that.

Keeping versions in complete sync is just impossible, even less so with IRSO having a large codebase itself.

[dtantsur]

Idea 2: use a sub-patch version (28.0.1.1 etc). Are we going to annoy people with that?

[tuminoid]

See my top-level comment, I cannot see this work really.

[dtantsur]

Idea 3 (also obvious): use independent versioning. How do people know which version of the operator installs which Ironic?

[tuminoid]

This gets my vote. Version(s) supported should be prominently visible in documentation. IRSO has substantial codebase of its own, and its worth independent versioning. If IRSO also publishes Go modules like BMO, it'd be making even less sense to bump majors.

[lentzi90]

+1 for this.

How do people know which version of the operator installs which Ironic?

If the operator needs to know the version (which I guess it does), then it should have a separate field for setting that version. The prometheus-operator is an example that works like this. If you set the version but not the image, then the operator picks the "standard" image for that version. If you set a custom image, you are also responsible for telling the operator what version it is related to.
Ref docs: https://prometheus-operator.dev/docs/api-reference/api/#monitoring.coreos.com/v1.PrometheusSpec (scroll down to see version and image).

[lentzi90]

Another example of how to solve the image/version issue is how cloudnative-pg does it. They have a separate CRD, ImageCatalog, that allows the user to list all custom images and their respective major version (which is all the operator cares about). That way they avoid the extra version field, at the cost of an entire extra CRD.

[Rozzii]

+1 independent with a standard/default ironic-image then the possibility to set different versions .

[tuminoid]

For example postgres-operator supports a range of postgres versions, it is not installing a single major version of postgres, much less matching versioning to minor or patch level. Since the operator is a lot of code that is not related to the product it operates, I'm voting for independent versioning.

[elfosardo]

not a lot to add here what Tuomo already wrote, I'm also for independent versioning as it just makes sense

[dtantsur]

@tuminoid @elfosardo okay, noted. I'm curious how supporting several versions may work in combination with custom images. If an operator or a downstream is using non-upstream image, should we: (a) assume version==latest, (b) expect them to provide a version mapping somehow (new CRD?).

[Rozzii]

I would just allow user to set a custom image with custom tag and it is their resposibility to make the image compatible. IMO if it is a custom image we will treat it as we would treat the upstream images the given version of the operator is compatible with.
I assume for each release of the IrSO we would state in release notes the range of compatible images and that range would be a subset (or equal set) of the supported ironic-image releases.

[elfosardo]

I kind of have the same thoughts as Adam, especially on being explicit on which versions of ironic-image are supported.
Better be very explicit there, we can always expand or reduce the list in case of changes or new releases.