The root cause is paunch CLI does not honor the passed --managed-by arguments, while when invoked via ansible playbook (as of train) - it does. For the latter case, it discovers the container and deletes it, so the deployment continues normally. For the former case, it cannot find the container because of mismatch in its lables=managed-by. It is not clear also, why inspecting the container under test also shows the wrong managed-by=paunch value, while we expect it to be tripleo-Undercloud, for example.
The root cause is paunch CLI does not honor the passed --managed-by arguments, while when invoked via ansible playbook (as of train) - it does. For the latter case, it discovers the container and deletes it, so the deployment continues normally. For the former case, it cannot find the container because of mismatch in its lables=managed-by. It is not clear also, why inspecting the container under test also shows the wrong managed-by=paunch value, while we expect it to be tripleo-Undercloud, for example.
Here is the reproduce scenario:
- hosts: Undercloud MINOR_UPDATE: false tripleo- config/ hashed- container- startup- config- step_1. json log_stdout_ path: /tmp/out disabled: true Undercloud"
tasks:
- name: Start containers for step 1 using paunch
environment:
TRIPLEO_
paunch:
config: /var/lib/
config_id: tripleo_step1
action: apply
container_cli: podman
container_
healthcheck_
managed_by: "tripleo-
debug: True
ansible-playbook -v -b -i undercloud- ansible- DFoHef/ inventory. yaml test.yaml
log: by=tripleo- Undercloud --filter label=config_ id=tripleo_ step1 --format .Names .Labels. container_ name
$ podman ps -a --filter label=managed_
sudo paunch --log-file /tmp/foo --debug apply --file /var/lib/ tripleo- config/ container- startup- config- step_1. json --container rabbitmq --config- id=tripleo_ step1 --managed- by=tripleo_ Undercloud
log: by=paunch --filter label=config_ id=tripleo_ step1 --format .Names .Labels. container_ name
$ podman ps -a --filter label=managed_
rabbitmq rabbitmq