Multiple base image support (and sambacc)

[phlogistonjohn]

I think there's potential value in supporting multiple base images.
I'm creating this topic for general discussion of that idea.

Additionally, one of the things that has complicated the build process is sambacc. So I will open up the discussion to include sambacc. I considered making it a separate discussion on the sambacc repo, but these are fairly related and I would rather have the conversation in one place.

I'll dive into details in a follow up message.

CC: @obnoxxx @spuiuk @synarete @anoopcs9 @dmulder @gd

[phlogistonjohn]

When sambacc was very new and experimental I didn't want to set up any "infrastructure" to use it. So I added the ability for the test container image to build python wheels. Then to build upon sambacc the samba-container images could just invoke the sambacc build image and build python wheels for every build. Later, we didn't like how the wheel was different from every other package in the container (rpm), so we added a way to build sambacc as RPMs. However, it continued to follow the same model -

• we FROM sambacc build image "AS builder"
• run the build script:
  • this checks out sambacc git repo
  • runs tests
  • runs python wheel build
  • runs rpm build
• the next container layer pulls in the wheel/rpm using COPY --from=builder
• sambacc is installed using a script
• all other rpm packages are installed using a script

A couple of thoughts on resources we could use to split things up more:

• We currently do not make (serious) use of pypi for python packaging
• We could consider the use of COPR for RPM packaging

I sill want an easy way to create rpm packages out of arbitrary versions locally, so I don't want to get rid of the script to build sambacc in a container, but for the more "typical" builds maybe something like the above can help.

As for building samba-container sever/client/etc images on different bases. I think it could just be a matter of supporting a --build-arg for the base image and then teaching the install-packages.sh script how to deal with multiple distros (examples: fedora, centos stream, opensuse, etc).

In some ways it would be similar to what we already do for the nightly images, just instead of altering our source for samba RPMs we are tweaking our general source for packages.

OK, this went a bit long but I hope it's good food for thought. Questions/comments/alternative ideas welcome!

[dmulder]

Here's an option for providing multiple base images:
https://github.com/edrevo/dockerfile-plus
This way we could have a 'base' Containerfile, which is imported by either distro Containerfile.
Unfortunately, it doesn't appear to work with podman though.

[dmulder]

Take a look at my attempt at this here: #103
This maybe isn't the best, but it's a step in the right direction perhaps. I think selecting a base image via an arg to the build command is a good approach, and I also think it would be best if sambacc were built and provided via COPR. The install phase is a mess though. I might be able to get direction on my side how to improve this.

[dmulder]

An alternative is the project could provide a Containerfile.opensuse, which is different from the regular Containerfile.

[dmulder]

My thoughts.

openSUSE builds images using our build service (similar to COPR, I believe), so we wouldn't really utilize the build/push/etc, aside from running make test. openSUSE also uses some custom labels and comments for the build process (see the openSUSE Containerfile for example). These could be merged and would just be ignored by fedora, I suppose.
Then perhaps the differing install commands could be handled in the install-packages.sh script.

You can view here how I've packaged sambacc in our build service. And then I've added this repository which includes sambacc as a dependency for building the images, and included sambacc in the install list.