Proposal: Multiple base images support

[dmulder]

This is a proposal for adding opensuse build support. It's a bit awkward in places, and I'll explain why.

The openSUSE build service requires the package install line to be in the container file. So installing from the install-packages.sh script isn't an option. This is because our build environment parses dependencies from that install line prior to performing the build.
The install command also must be within the first 2 lines of the RUN command, sigh. This is possibly a bug in our build code.

One required change from Fedora would be to add sambacc to COPR, so that it can be installed via yum.

[phlogistonjohn]

The openSUSE build service requires the package install line to be in the container file. So installing from the install-packages.sh script isn't an option.

Oh, that's really unfortunate. I was hoping that all the "business logic" could be neatly contained within the script.
Many of the other parts seem reasonable, although I'll have to look more closely at the LABELs.

I'll mediate some on these and also ask for some of the others to also take a look. Thanks a ton for submitting this PR!

[phlogistonjohn]

CC: @synarete @anoopcs9 @obnoxxx for general feedback

[dmulder]

Oh, that's really unfortunate. I was hoping that all the "business logic" could be neatly contained within the script. Many of the other parts seem reasonable, although I'll have to look more closely at the LABELs.

I'll poke around and see if there is some way around this (and maybe ask around).

[synarete]

I disagree with the overall approach.
IMHO, it is better to have multiple Containerfiles and pass the relevant one as variable to make.

[synarete]

I disagree with this approach. Different base os-image implies different installer-program (dnf, zypper, apt..) as well as different list of packages names. It requires adding ifs within the Containerfile which makes it hard-to-read and hard-to-maintain over time.

IMHO, a better approach would be to have multiple Container files per base OS and pass it as argument to top-level Makefile.

[synarete]

I would prefer to have different Containerfiles and pass it as (optional) argument to Makefile. See my comments below.

[phlogistonjohn]

I like the --build-arg approach iff it reduces the delta between supported versions, but otherwise I agree here that it doesn't seem to streamline the approach

[synarete]

Those standard annotations are good idea and should probably be used in all of SINK containers.

[synarete]

However, this annotation is OpenSUSE specific and should be only in OpenSUSE specific container file (something like Containerfile.opensuse).

[synarete]

Those type of if-else are a nightmare to maintain. Think of all the other distros out there -- would to like to have a long if-else within the Containerfile itself?

[dmulder]

I tend to agree with @synarete. I put this together as a proof of concept, and it is ugly. I think having a container file for each distro may be best.

[phlogistonjohn]

I tend to agree with @synarete. I put this together as a proof of concept, and it is ugly. I think having a container file for each distro may be best.

I think that's probably for the better too.

I wouldn't mind so much a bunch of if statements inside a proper shell script, after all what's a script for? But agree that putt a lot of logic inside the containerfile is ugly. I do like the idea of supporting multiple distro bases so that we have a common upstream "home" for samba container images - I think it's better for collaboration and sharing common bits (where possible) and tests.

[dmulder]

I wouldn't mind so much a bunch of if statements inside a proper shell script, after all what's a script for? But agree that putt a lot of logic inside the containerfile is ugly. I do like the idea of supporting multiple distro bases so that we have a common upstream "home" for samba container images - I think it's better for collaboration and sharing common bits (where possible) and tests.

I think I'll still ask around and see if I can work around the install line being in the Containerfile. If that weren't an issue, this solution would be much cleaner.

[dmulder]

I think I'll still ask around and see if I can work around the install line being in the Containerfile. If that weren't an issue, this solution would be much cleaner.

I asked our build team, and they recommend we simply maintain multiple Containerfiles. Our build system builds images offline. So it parses the Containerfile for package install commands, then injects the required packages into the build environment.

[synarete]

I think I'll still ask around and see if I can work around the install line being in the Containerfile. If that weren't an issue, this solution would be much cleaner.

I asked our build team, and they recommend we simply maintain multiple Containerfiles. Our build system builds images offline. So it parses the Containerfile for package install commands, then injects the required packages into the build environment.

As a side note: we currently use fedora:36 as base image, which are publicly available (no need to login to any registry). Which BASE_IMAGE do you want to use? is it publicly available?

[dmulder]

I wouldn't mind so much a bunch of if statements inside a proper shell script, after all what's a script for? But agree that putt a lot of logic inside the containerfile is ugly. I do like the idea of supporting multiple distro bases so that we have a common upstream "home" for samba container images - I think it's better for collaboration and sharing common bits (where possible) and tests.

I've filed an issue requesting some kind of work around, so we could perhaps explore a single Containerfile again in the future.

[dmulder]

As a side note: we currently use fedora:36 as base image, which are publicly available (no need to login to any registry). Which BASE_IMAGE do you want to use? is it publicly available?

We use the base image opensuse/tumbleweed, which is also publicly available (it's hosted from registry.opensuse.org). We will use other public base images at some point, but for now I'm testing everything against Tumbleweed (which is similar to Fedora Rawhide).

[dmulder]

I'm going to close this request and create a new one with distro-specific Containerfiles.