Different podman-auto-update intervals for different containers

[mqus]

Hey!
Currently I have the use case that I want to run multiple containers via podman&systemd but in kinda different scenarios. There is one type of container that only should be updated once a week (infrastructure like databases & stuff, let's call it type A) and there are the containers I'm actually working on, some application etc, that I want to get updated as soon as I push a new image to my registry (with the appropriate tag), lets call it type B.

Right now, I can only enable/disable containers for auto-update and can enable (and configure) the timer unit. But all that does is either update all tagged images, or, if I disable the timer, none of them.

To enable this "deploy ASAP"-functionality for type B, I would also have to set the timer to an interval of something like 5-30s and I noticed that the default output of podman-auto-update can be somewhat spammy. I could probably mitigate that by hacking together a template for --format, but I wish there was a simpler pre-made output like "container x was updated" which gets shown only when it actually got updated, maybe behind a -q flag.

So here is my question:
Is there a way to have my cake and eat it, too? Meaning I can regularly and stably update my infrastructure, type-A containers and have my app at the bleeding edge, all in an automatic fashion? I should probably mention that my host is on debian bookworm, which is currently running podman 4.3.1 (so no quadlets).

[Luap99]

It is not possible to only update certain containers with auto-update, although I guess it would#t be difficult to implement something like this.

That said if you talk about an interval like 5s then I think podman auto-update is the wrong tool. This would spam the registry a lot. Since you control the images it would be munch better to send some form of push notification to your host when you publish a new image. Polling in such a short interval seems very expensive.

[mqus]

The interval of 5s results from a workflow that e.g. watchtower seems to support, where a "push to registry" then results in an immediate redeploy. Of course in practice something like 30s is still alright, but it shouldn't be much longer. I thought that auto-update would be a kind of replacement for watchtower (obviously a bit different, but still), but maybe I misunderstood. Sorry, my fault. It seems I misunderstood watchtower here. It also polls and has a minimum interval

[rhatdan]

@vrothberg PTAL

I think it would be better to setup systemd timers for specific containers that need to be updated once per week.

[vrothberg]

At the moment, it is not possible to auto-update only specific containers. But all containers configured for auto-updates will be checked and updated if needed when podman auto-update runs.

The basic assumption is that the admin decides to update the fleet by pushing a new image. A git-ops workflow in a way.

To be able to update only a subset of containers, I suggest to think about adding a --filter flag where only containers matching the specified filters will be considered for auto updates. This would also allow for implementing custom logics on top.

For instance, type A containers would be created with --annotation type=a. Updating those containers would require filtering for the type=a annotation.

[mqus]

a --filter option was also what I expected, but did not find. So I think this would be a good addition. A workaround I have in my mind is: setting the containers that shouldn't be polled as frequently to io.containers.autoupdate=local and have a systemd timer (or cron job) that pulls the relevant images once a week. So auto-update would still run very often but will only pick up some containers sometimes.

If I understood local right, this might work.