Charts: add registry templating to support Elemental airgap scenarios

[fgiudici]

The chart has the .Value.registry_url variable now.
By default it will point to the "official" registries ("registry.suse.com" or even "registry.opensuse.org/isv/rancher/elemental/dev/containers") but if set during chart installation (--set registry_url=$MY_PRIVATE_REGISTRY:$PORT) it will allow to point to a private registry.
Worth to noting that the registry templating is done in such a way to support and not confllct with the Rancher Marketplace templating once the Elemental charts will land there.

Rancher annotations have been updated too.

Last note: this PR changes the makefile to set the default values of the container images to point to the images built on OBS Dev channel. This may be of help when reviewing the github release process (to allow pointing directly at OBS images).

Fixes #496

[codecov]

Codecov Report

Patch and project coverage have no change.

Comparison is base (ffb9c01) 51.50% compared to head (ea19355) 51.50%.
Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #497   +/-   ##
=======================================
  Coverage   51.50%   51.50%           
=======================================
  Files          41       41           
  Lines        5551     5551           
=======================================
  Hits         2859     2859           
  Misses       2443     2443           
  Partials      249      249           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[fgiudici]

While the chart building test fails (as the expected image references are different now) and should be fixed before merging, would be good to get some reviews here.
Tested successfully in an online environment (performed update) and on an airgapped one (installed, loading the elemental-operator and seedimage-builder images in a private registry first and installing the helm chart with --set registry_url )

[anmazzotti]

Looks good to me beside the kube-version and rancher-version ranges.
They are nice to have, I'm more curious about the values.

[anmazzotti]

how/where did you define this range?

[fgiudici]

This is a mandatory annotation for the Rancher Marketplace: since these annotations are for Rancher only, seems to me that makes sense to add all the required ones.
Kubernetes 1.23 is the minimal version supported by Rancher 2.7.x and we require Rancher 2.7.x.
Kubernetes 1.28 is just an high Kube version: the value is arbitrary high and the common one used in the Rancher 2.7 marketplace.
I don't think this restriction will be put in place ever, in any case I wish that for Kube 1.28 users will install a newer chart version 😄

[anmazzotti]

Same here, this also seem rather strict

[fgiudici]

Well, this is different IMO: we don't support Rancher 2.6.x.
Moreover, we don't know if this chart will be compatible with Rancher 2.8.0: a lot could change there.
We will expand the supported versions when needed, but for sure we want the older chart versions to disappear by default from the marketplace for future Rancher versions (we want to release newer charts... or rebuild the same with updated tags is needed after proper testing).
This also is a common pattern in Rancher Marketplace charts.

[davidcassany]

The target of this PR is unclear to me, shouldn't this be applied to the OBS chart?
These changes will mostly not land in OBS (they should be applied on .obs/charts/*) and eventually break it depending on the specific changes.

I'd be in favor of moving the charts to some sort of github release that is consumable according to the marketplace needs. And get rid of the charts in OBS completely. @fgiudici shall we create a new card for that or this is already in progress somewhere?

[fgiudici]

The target of this PR is unclear to me, shouldn't this be applied to the OBS chart? These changes will mostly not land in OBS (they should be applied on .obs/charts/*) and eventually break it depending on the specific changes.

The target of these changes is to support templating for an airgapped scenario (and for Rancher Marketplace too).

I'd be in favor of moving the charts to some sort of github release that is consumable according to the marketplace needs. And get rid of the charts in OBS completely. @fgiudici shall we create a new card for that or this is already in progress somewhere?

That it is tracked in #460 , which blocks on the Rancher Marketplace release (#376).
This fixes #496 which is part of #376. This is somehow an intermediate step.
Still, the templating has effects on the github workflows that should be updated and fixes in this PR 😓

[davidcassany]

The target of this PR is unclear to me, shouldn't this be applied to the OBS chart? These changes will mostly not land in OBS (they should be applied on .obs/charts/*) and eventually break it depending on the specific changes.

The target of these changes is to support templating for an airgapped scenario (and for Rancher Marketplace too).

Sure, however by the target I meant where do you expect the changes to be effective, I mean, why those changes are not applied in .obs/chartfile/crds/Chart.yml and .obs/chartfile/operator/Chart.yaml, etc. To me it looks like they should be there too as these are the actual charts we are releasing. Hopefully we can get rid of one of the two in #333 and #460 scope, but IMHO meanwhile we should keep all chart changes, at least, in OBS if not both.

[fgiudici]

why those changes are not applied in .obs/chartfile/crds/Chart.yml and .obs/chartfile/operator/Chart.yaml, etc. To me it looks like they should be there too as these are the actual charts we are releasing. Hopefully we can get rid of one of the two in #333 and #460 scope, but IMHO meanwhile we should keep all chart changes, at least, in OBS if not both.

You are absolutely right! Synced OBS charts.

[davidcassany]

Nice! 👍 now it will land in OBS too 😉