Set a packaging strategy to maintain multiple elemental-operator versions for a single OS stream (aka SLE Micro 5.5 in this case)

[davidcassany]

So far I can't think of any other alternative of duplicating OBS packages for which the sources are coming from elemental-operator repository. This impacts:

• elemental-operator-crds-helm
• elemental-operator-helm
• elemental-operator
• operator-image
• seedimage-builder

The container images and helm charts should only be renamed at OBS level, but in the registry they should be still named the same (current pulling from v1.4.x branch and the new ones from v1.5.x branch). Container images for v1.5.x branch should pull packages for elemental-operator v1.5.x branch and vice versa for v1.4.x branch for the already existing images. That is likely to imply a different package name for each elemental-operator RPM (including subpackages), this way we can keep building both. I'd suggest adding a suffix to each artifact (what about 1.5? any other brilliant idea for a code name? not sure using a number won't raise any issue). So that it could be translated as:

• elemental-operator-crds-helm1.5 (no source changes expected other than pulling from the specific branch)
• elemental-operator-helm1.5 (no source changes expected other than pulling from the specific branch)
• elemental-operator1.5 (spec changes to rename all subpackages and include conflicts to older versions)
• operator-image1.5 (changes in the Dockerfile to make use of v1.5.x package series explicitly)
• seedimage-builder1.5 (changes in the Dockerfile to make use of v1.5.x package series explicitly)

So yet another branch is required for v1.5.x for SLE Micro 5.5 specific builds as several source changes are required.

[davidcassany]

Prepared a POC here https://build.opensuse.org/project/show/home:dcassany:branches:isv:Rancher:Elemental:Maintenance:5.5

This requires creating/duplicatin six packages and the adaption of project configuration and former elemetal-channel image. Not really satisfied with this approach. To proceed with this I'd repurpose v1.5.x branch of elemental-operator for Micro5.5 and bump to v1.6.x for Micro 6.0 to make elemental-operator maintenance clearly on separate branches that land in separate projects in OBS.

Drafted source changes here https://github.com/rancher/elemental/issues/1335

[davidcassany]

Done, isv:Rancher:Elemental:Maintenance:5.5 includes packages for both versions of the operator v1.4 and v1.5