force_restart: true ignores any changed parameters in container task
#816
Comments
va1entin
changed the title
force_restart: true ignores any changed parameters in playbookforce_restart: true ignores any changed parameters in container task
|
Hi, @va1entin - containers.podman.podman_container:
name: nginx
state: started
force_restart: trueWhen you change the container definition I don't see why to use |
|
Hi @sshnaidm thanks for your swift reply and view on the matter!
I think there is a use case in adding force_restart to the container definition rather than a separate task as in your example because that allows you to have a more concise playbook in some cases. You can have the container definition and the restart in one task rather than having two separate tasks. If the container definition doesn't change you can rest assured that the container will be restarted without needing a separate task and if the definition does change the changes will be applied. In fact that is essentially my use case: I have two container definitions in my playbook and usually only one of them changes at a time because of version updates or so. With force_restart I can ensure that the other, unchanged, container will still be restarted without needing a separate job. It's a bit of a special use case but feels valid to me in the spirit of keeping playbooks DRY. |
|
@va1entin let me understand better your case. Do you restart the second container only if first changed? In this case it's better to have a condition: - name: First container
podman_container:
name: first
...
register: first
- name: Second container
podman_container:
name: second
....
- name: Restart second if first has changed
podman_container:
name: second
force_restart: true
when: first is changed
I can't think about a use case when you need to restart the container every time you run the playbook. Do you have such? |
|
@sshnaidm Currently, I don't restart the second container only if the first changed. Restarting the container every time is not mandatory in my setup but I like to do it to ensure that a change in container 1 doesn't disrupt the functionality of container 2, even if the latter is restarted. While it's hopefully rare, I have seen cases where only a restart of the app exposes a problem that wouldn't immediately appear during normal operation when something is changed in a container that this app relies on. Such problems might otherwise only manifest way later when one wouldn't necessarily connect it to the container update one did potentially days or weeks ago, depending on when the container is restarted next. Apart from changes in the containers themselves, the restart could also exposes new problems between host and containers that might only show way later - which makes it useful regardless of whether the container definitions changed. In essence, containers should survive restarts at any point and services should not or only minimally be disrupted when they happen - otherwise that's an indication for a problem in my setup and having every playbook run restart the container gives me an opportunity to add that "restart test case" into my playbook very leanly. |
|
I still not fully understand your use case, but anyway - if we start require all settings to be in container definition with |
|
We are also affected from the issue 😢 |
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
Hi team, I'm filing this as a bug but it could be just a docs bug if the behavior I'm describing is actually desired. When
force_restart: trueis set on apodman_containertask and the container already exists,podman_containerwill ignore any parameters changed in the task.For example, you could deploy a Ubuntu
22.04container withforce_restartset totrue. The container then exists on the target host. Then you change the image to Ubuntu24.04and run the playbook again. The container will be restarted but the new image will be ignored. This applies at least toimageandcommandbut looking at make_started I'd assume it applies to any parameter.The return statement here means the function will always return before any parameter changes to containers are made if
restart/force_restartaretrue.I also couldn't find anything in the docs describing this behavior and iirc the docker container module doesn't do it this way either.
Personally, I don't think
force_restartshould mean "do only a restart and literally NOTHING else". If I needforce_restartfor some reason that means I have to set it tofalseevery time I want to change anything about my container or create a second task that only contains the containername,imageandforce_restartto have a "restart only" task and then a separate task that contains my actual container parameter. This seems very counterintuitive and might have unforeseen consequences that I don't see right now.My proposal is to remove the return statement linked above. That means after the restart is done, the rest of
make_startedwill still be executed and changed parameters will be reflected on the target host. There might be downsides to this particular approach that I don't see. For example,update_container_result()could be called twice in one run ofmake_started()- I think that will be a problem or at the very least the restart information might be lost.If you don't agree with my understanding of
force_restartand do think that the default whentrueshould be to ignore any changed parameters, one could also leverage therecreateparameter here, check whether it'strueand only then apply changed parameters whenforce_restart: true. Currently, even withrecreate: truemy container will not be recreated as long asforce_restartistrueas far as I could tell.Happy to create a PR for this by the way - just wanted to discuss whether this behavior is desired and which approach would be best before I do. 😃
Steps to reproduce the issue:
Deploy a container with
force_restart: trueChange a container parameter like
imageorcommandin the playbook and run it againContainer will be restarted but your changed parameter will not be reflected;
image/commandor whatever will not be changed to what you set in step 2 until you setforce_restarttofalseand re-run the playbookDescribe the results you received:
Containers are restarted but updated parameters are not reflected when
force_restart: trueDescribe the results you expected:
Containers are restarted and updated parameters are reflected when
force_restart: trueAdditional information you deem important (e.g. issue happens only occasionally):
Version of the
containers.podmancollection:Either git commit if installed from git:
git show --summaryOr version from
ansible-galaxyif installed from galaxy:ansible-galaxy collection list | grep containers.podmanOutput of
ansible --version:Output of
podman version:Output of
podman info --debug:Package info (e.g. output of
rpm -q podmanorapt list podman):Playbok you run with ansible (e.g. content of
playbook.yaml):Command line and output of ansible run with high verbosity
Please NOTE: if you submit a bug about idempotency, run the playbook with
--diffoption, like:ansible-playbook -i inventory --diff -vv playbook.ymlAdditional environment details (AWS, VirtualBox, physical, etc.):
The text was updated successfully, but these errors were encountered: