Comment 12 for bug 1853812

Revision history for this message
Bogdan Dobrelya (bogdando) wrote :

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
  tasks:
 - name: Start containers for step 1 using paunch
   environment:
  TRIPLEO_MINOR_UPDATE: false
   paunch:
  config: /var/lib/tripleo-config/hashed-container-startup-config-step_1.json
  config_id: tripleo_step1
  action: apply
  container_cli: podman
  container_log_stdout_path: /tmp/out
  healthcheck_disabled: true
  managed_by: "tripleo-Undercloud"
  debug: True

ansible-playbook -v -b -i undercloud-ansible-DFoHef/inventory.yaml test.yaml

log:
$ podman ps -a --filter label=managed_by=tripleo-Undercloud --filter label=config_id=tripleo_step1 --format .Names .Labels.container_name

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:
$ podman ps -a --filter label=managed_by=paunch --filter label=config_id=tripleo_step1 --format .Names .Labels.container_name
rabbitmq rabbitmq