Helm chart release and maintenance flow in OBS

[davidcassany]

In our current helm chart builds in OBS isv:Rancher:Elemental:Dev or isv:Rancher:Elemental:Staging the repository of the elemental operator image is set in _services to be replaced at build time to a value that is dependent on the OBS project path. This bad because it means OBS sources needs to be adapted depending on the project the build is happening. In an RPM context I would simply solve this by setting some macro in the project configuration, something like %define repo <published repository> and make use of such a variable in spec. This way it would be possible to move sources from project A to project B without having to modify them as the project configuration of each would include the value of the appropriate repository. This is relevant for testing, so we can test in project A and submit to project B without modifying the sources and being sure they are the same.

This card is about finding a solution for the eventual chart build in isv:Rancher:Elemental:Stable, which should include exact same sources in IBS and the build should be functional in both cases.

[kkaempf]

Uhm, not sure how to solve this.

(Trying to be explicit here for those without IBS knowledge :wink:)

There are (resp. will be) 3 builds in IBS

1. Devel:Elemental - linked to ...:Stable
2. SUSE:Maintenance:... (tbd) - the 'staging' project for every maintenance update requested by us. <- this is what we need to test
3. SUSE:...:Elemental (tbd) - the official build project, owned by maintenance - this is synced to registry.suse.com

We can only influence 1. and submit to 2. Copying from 2. to 3. is not in our hands.

[davidcassany]

I was wondering if there was a way to add environment variables to the build env from project configuration or something similar, in that case we could define some build service to actually run a replacement based on some env variable.

[davidcassany]

My idea is to expand the obs-service-replave_using_env to support expanding from rpm macros too, so we could eventually have something in services like:

<services>
  <service name="replace_using_env" mode="buildtime">
    <param name="file">values.yaml</param>
    <param name="macro">image_repo</param>
  </service>
</services>

and project configuration including:

%define image_repo registry.opensuse.org/my/project/path/repository

and a values.yaml with

...
  repository: "%%image_repo%%"
...

It is a damn simple bash script and the new --macro flag would simply call rpm -E "%<macro_flag_value>", as macros define in project configuration are included into the build environment as part of ~/.rpmmacros

[davidcassany]

Ok, I managed to solve this, there was no need to modify any obs-service for that. replace_using_env is already capable of doing what I had in mind, probably not in very elegant way, but doable.

Now none of the builds in isv:Rancher:Elemental:Dev and its Teal53 makes use of any registry.opensuse.org/isv/rancher/...

Instead this value is set as a macro in project configuration. For instance in Dev:Teal53 project conf I added the %img_repo macro

Macros:
%img_repo registry.opensuse.org/isv/rancher/elemental/dev/teal53/15.4
:Macros

This macro is then loaded and used by the repolace_using_env service as:

  <!-- 
      This service is actually replacing the IMG_REPO placeholder with
      the '%img_repo' rpm macro set project configuration. So far this
      is only way we could find to retrieve project config information
      at buildtime for a non spec recipe.
  -->
  <service name="replace_using_env" mode="buildtime">
    <param name="file">Dockerfile</param>
    <param name="eval">IMG_REPO=$(rpm --macros=/root/.rpmmacros -E %img_repo)</param>
    <param name="var">IMG_REPO</param>
  </service>

Then the Dockerfile includes:

LABEL org.opensuse.reference="%%IMG_REPO%%/rancher/elemental-operator/5.3"

This way the reference is computed at buildtime based on project configuration. This allows to move around the sources without having to actually modify sources. @kkaempf I believe this is handy for IBS, as with this we can have the same exact sources as in OBS Stable (hence a link) and set the project configuration in IBS with:

Macros:
%img_repo registry.suse.com
:Macros

This does not solve the maintenance incident copy issue but to tests in that area we could consider k3s config as documented here. To my eyes what we gain here is having the same exact sources in OBS and IBS allowing us to heavily relay on the tests we do in the open before submitting.

[davidcassany]

I consider this done. The macro setup has been included in the Elemental OBS builds confluence page with a link to this issue for full reference if needed.