-
Notifications
You must be signed in to change notification settings - Fork 122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Container image name not updated when image registry changes #485
Comments
I think the problem is that right now, the module checks whether the image ID differs, and doesn't care about the image name. (Since in the end the relevant thing is the image ID, not its name.) Am I assuming correctly that in your case, the same image is available under two different names, and you want to make sure that the container isn't simply using the correct image, but that the
The image doesn't need to update, since both names refer to the same image in your case. What you want is the image name to change in the container config, not the image that's used. |
Yes, what I think should happen is that when the image attribute in yaml changes that the image name of the currently existing container should be changed to match the new name, such that they stay in sync, and can be used by watchtower to pull new images. To summarize below, the the details are in the Watchtower discussion. The problem is that Watchtower logic needs to know how to recreate the container when it updates the image, and watchtower uses the container image attribute, when Ansible changes the image backing the container but not configured container image name, the image does not match, and watchtower fails. The problem happened to me because I changed the image in yaml from In many cases the same image name at different public registries may be the same, it need not be, |
Since the current behavior has been the default for some time now, I'm wondering whether this should be more a bugfix (i.e. change the behavior) or a new feature (allow to change the behavior by setting an option). It might well be that someone already depends on the current behavior. I'm currently tending to treat this more like a new feature, i.e. have an option which allows to control the behavior. We can still deprecate the current default (i.e. doing the old behavior) so that folks have some time to notice that the behavior will change, and already adjust their playbooks/roles to the new behavior. |
Yes I understand the difficulty of it is not a bug it is a feature. I have some thoughts:
|
I don't think this makes sense, since |
I created a PR for a new option I think the default value (right now: |
Thank you, agree, recreate should (eventually) be default. |
In case it helps somebody: I changed a couple container configs to pull from docker.io instead of from ghcr.io and lscr.io because I find GHCR is too unreliable with frequent broken pipe errors (lscr.io is a CNAME for ghcr.io). E.g. I added Next morning Watchtower was unhappy and complained that images could not be found. I deleted all containers and images. |
I started the deprecation process for the current default in #703. |
The default changed in 4.0.0, so this is now finally completely fixed. (If not, please explain what's missing.) |
SUMMARY
I discovered the issue when I change several LSIO containers to pull from
linuxserver/heimdall:latest
tolscr.io/linuxserver/heimdall:latest
.The problem manifested as Watchtower that reported
Unable to update container "/plex": Error: No such image: linuxserver/plex:latest. Proceeding to next.
After some discussions with Watchtower I discovered that the problem may have been due to the container not being recreated when the image changed.
Before I changed
recreate
toyes
:After I changed recreate to
yes
:ISSUE TYPE
COMPONENT NAME
community.docker.docker_container
ANSIBLE VERSION
COLLECTION VERSION
CONFIGURATION
OS / ENVIRONMENT
Proxmox 7.2
STEPS TO REPRODUCE
EXPECTED RESULTS
I would like the
recreate: no
logic to be aware of the current and new image name, and either fail the operation when the image changes, or update the image, including updating to the new registry if different.ACTUAL RESULTS
When changing the image registry, the image name does not get updated to reflect the new registry.
The text was updated successfully, but these errors were encountered: