trying out patches to services is hard

[evgeni]

So I wanted to give https://github.com/theforeman/smart_proxy_pulp/pull/40 a go in the quadlet setup I have…

I had to create a Containerfile:

FROM quay.io/evgeni/foreman-proxy-rpm:3.12
USER root
RUN dnf install -y https://download.copr.fedorainfracloud.org/results/packit/theforeman-smart_proxy_pulp-40/rhel-9-x86_64/08129033-rubygem-smart_proxy_pulp/rubygem-smart_proxy_pulp-3.3.0-2.20241011111146235873.pr40.2.g4ce3ca5.el9.noarch.rpm
USER foreman-proxy

Build it:

podman build -f Containerfile -t quay.io/evgeni/foreman-proxy-rpm:3.12-patched

Then update /etc/containers/systemd/foreman-proxy.container to use the new tag, systemctl daemon-reload, systemctl restart foreman-proxy (maybe I could save the first two if I'd have re-used the tag, but then I wasn't sure podman won't try to re-pull from quay).

That's… suboptimal.

[ekohl]

Then update /etc/containers/systemd/foreman-proxy.container to use the new tag, systemctl daemon-reload

Could you use systemctl edit foreman-proxy.container to create a drop-in file? I think that also executes the daemon-reload for you.

I wasn't sure podman won't try to re-pull from quay

Pretty sure it can be configured to pull the latest version of a tag, depending on how you set it up.

[evgeni]

Could you use systemctl edit foreman-proxy.container to create a drop-in file? I think that also executes the daemon-reload for you.

Nope. systemctl edit is for systemd files, but the .container file is podmans. The generator is what translates it to systemd.

[ehelms]

There are two parts. The fundamental where we, no matter what, would have to:

• Have a new build of the container containing the patch
• Pull that new image to the host
• Restart systemd service

The parts we can influence are the technique by which those happen and are orchestrated.

According to https://docs.podman.io/en/latest/markdown/podman-auto-update.1.html we could use local to have it auto-restart on podman pull or podman build (if the build is local). This probably isn't what we'd want in production but could make development and patch testing easier / faster.

[ekohl]

Nope. systemctl edit is for systemd files, but the .container file is podmans. The generator is what translates it to systemd.

Ok, but the docs say you can use drop in files so we can adopt a pattern where if you need to patch, you create the drop in, reload and restart. Dropping the patch is the opposite: remove the file, reload and restart.

What I like about that is that we can easily separate it from the production flows and leave those untouched with relative simple logic. If at some point we decide that we want to ship the .container files in some RPM (to /usr/share/containers/systemd) then the patching workflow still applies.