all:
  children:
    zuul_unreachable:
      hosts: {}
  hosts:
    debian-bookworm:
      ansible_connection: ssh
      ansible_host: 2a13:1a81:8000:3124:f816:3eff:fe03:a1f
      ansible_molecule_ansible_version: 12.3.0
      ansible_port: 22
      ansible_python_interpreter: auto
      ansible_role: manager
      ansible_user: zuul
      nodepool:
        az: nova
        cloud: regiocloud-a-ci
        external_id: 2f0753b6-2534-49e1-a33c-899de87b0b55
        host_id: 82101243836454d7401d5893feae9e2c5df7cc291646d8a99b33b53b
        interface_ip: 2a13:1a81:8000:3124:f816:3eff:fe03:a1f
        label: debian-bookworm
        node_properties: {}
        private_ipv4: 10.128.7.70
        private_ipv6: null
        provider: regiocloud-a
        public_ipv4: 81.163.192.39
        public_ipv6: 2a13:1a81:8000:3124:f816:3eff:fe03:a1f
        region: null
        slot: null
    ubuntu-noble:
      ansible_connection: ssh
      ansible_host: 2a13:1a81:8000:3124:f816:3eff:feb0:c77b
      ansible_molecule_ansible_version: 12.3.0
      ansible_port: 22
      ansible_python_interpreter: auto
      ansible_role: manager
      ansible_user: zuul
      nodepool:
        az: nova
        cloud: regiocloud-a-ci
        external_id: 1752ac8a-5547-4ed0-9519-70419d08ca28
        host_id: 5afd8fc909abddfe2ce3a956a91bbe56629648b7209fd0acfa541862
        interface_ip: 2a13:1a81:8000:3124:f816:3eff:feb0:c77b
        label: ubuntu-noble
        node_properties: {}
        private_ipv4: 10.128.7.219
        private_ipv6: null
        provider: regiocloud-a
        public_ipv4: 81.163.192.126
        public_ipv6: 2a13:1a81:8000:3124:f816:3eff:feb0:c77b
        region: null
        slot: null
  vars:
    ansible_molecule_ansible_version: 12.3.0
    ansible_role: manager
    zuul:
      _inheritance_path:
      - '<Job base explicit: None implied: {MatchAny:{ImpliedBranchMatcher:main}}
        source: osism/zuul-config/zuul.d/jobs.yaml@main#2>'
      - '<Job ansible-molecule explicit: None implied: {MatchAny:{ImpliedBranchMatcher:main}}
        source: osism/zuul-jobs/.zuul.yaml@main#12>'
      - '<Job abstract-ansible-collection-services-molecule explicit: None implied:
        {MatchAny:{ImpliedBranchMatcher:main}} source: osism/ansible-collection-services/.zuul.yaml@main#79>'
      - '<Job ansible-collection-services-molecule-manager explicit: None implied:
        {MatchAny:{ImpliedBranchMatcher:main}} source: osism/ansible-collection-services/.zuul.yaml@main#267>'
      - '<Job ansible-collection-services-molecule-manager explicit: None implied:
        None source: osism/ansible-collection-services/.zuul.yaml@main#489>'
      ansible_version: '9'
      attempts: 1
      branch: main
      build: 4eb92f2c6c9946c68f0e8970b1f87f4f
      build_refs:
      - branch: main
        change: '2150'
        change_message: "manager: retry image pull on transient errors\n\n## What\n\nAdd
          `retries: 3` / `delay: 30` to the manager role's `Pull container images`\ntask.
          Two lines, no behaviour change on the happy path.\n\n## Why\n\nThe manager
          compose file pulls two third-party images straight from Docker Hub\nby design:
          `docker_registry_service` defaults to `docker_registry`\n(`index.docker.io`),
          so `mariadb` and `redis` come from there, while the\nOSISM-built images
          resolve via `docker_registry_ansible` to\n`registry.osism.tech`. In a rendered
          `/opt/manager/docker-compose.yml`, 10 of 12\nimages come from `registry.osism.tech`
          and exactly those two from\n`index.docker.io/library/`.\n\nDocker Hub is
          therefore a hard dependency we do not control, and it both\nreturns transient
          5xx and rate limits anonymous pulls. The task had no retry, so\none bad
          response failed the task and with it the whole manager phase.\n\nObserved
          on a fresh manager bootstrap:\n\n```\n[ERROR]: Task failed: Module failed:
          Error when processing image\nindex.docker.io/library/mariadb:11.8.8: Error
          response from daemon:\nHead \"https://registry-1.docker.io/v2/library/mariadb/manifests/11.8.8\":\nreceived
          unexpected HTTP status: 502 Bad Gateway\n```\n\nRetrying the same pull by
          hand immediately afterwards succeeded 3/3, so the\nerror was transient.\n\nWorth
          noting for anyone triaging a similar report: `docker compose pull` aborts\nevery
          image once one of them errors, so the concurrently pulling\n`registry.osism.tech`
          images were additionally reported as `Interrupted`. That\nmakes the failure
          look like a broad registry outage when it is a single image.\n\n## This
          was the only pull site without a retry\n\n| Site | Retry |\n|---|---|\n|
          `roles/netbox/tasks/service.yml` (compose pull) | `retries: 3`, `delay:
          30` |\n| `roles/netbox/tasks/restart-service.yml` (postgres, `docker_image`)
          | `retries: 3`, `delay: 30` |\n| `roles/stepca/tasks/service.yml` (compose
          pull) | `retries: 3`, `delay: 30` |\n| kolla-ansible `service-images-pull`
          | `retries`/`delay` + `until: result is success` |\n| `roles/manager/tasks/service.yml`
          | **none** |\n\nSo this reuses an established pattern rather than introducing
          one. The task is\nnow identical to the netbox sibling apart from the service
          name.\n\n## On the absent `until`\n\n`until` is omitted deliberately, to
          match the two sibling tasks. It is still\neffective, which is worth stating
          because the Ansible docs say `retries` \"is\nonly used in combination with
          `until`\":\n\n`ansible-core` computes `retries = 1 + max(0, task.retries)`
          and, when `until`\nis unset, falls back to an implicit condition on the
          task not having failed \u2014\n`cond.when = self._task.until or [not result['failed']]`
          in\n`executor/task_executor.py`. This therefore yields four attempts that
          stop as\nsoon as the pull succeeds. Verified against ansible-core 2.18,
          the series\ncurrently pinned.\n\nIf reviewers would rather be explicit,
          adding `register: result` +\n`until: result is success` here (and to the
          two siblings, for consistency) is a\nreasonable alternative \u2014 I kept
          the diff minimal instead.\n\n## Risk\n\nLow. On success the task behaves
          exactly as before. On failure it now takes up\nto 90s longer before failing
          the phase.\n\n\U0001F916 Generated with [Claude Code](https://claude.com/claude-code)\n"
        change_url: https://github.com/osism/ansible-collection-services/pull/2150
        commit_id: e7397d1e94a5612c66aa9e5308de3677ce5739e4
        patchset: e7397d1e94a5612c66aa9e5308de3677ce5739e4
        project:
          canonical_hostname: github.com
          canonical_name: github.com/osism/ansible-collection-services
          name: osism/ansible-collection-services
          short_name: ansible-collection-services
        src_dir: src/github.com/osism/ansible-collection-services
        topic: null
      buildset: 9472fa953fcf48cca3a6b5a0472cd032
      buildset_refs:
      - branch: main
        change: '2150'
        change_message: "manager: retry image pull on transient errors\n\n## What\n\nAdd
          `retries: 3` / `delay: 30` to the manager role's `Pull container images`\ntask.
          Two lines, no behaviour change on the happy path.\n\n## Why\n\nThe manager
          compose file pulls two third-party images straight from Docker Hub\nby design:
          `docker_registry_service` defaults to `docker_registry`\n(`index.docker.io`),
          so `mariadb` and `redis` come from there, while the\nOSISM-built images
          resolve via `docker_registry_ansible` to\n`registry.osism.tech`. In a rendered
          `/opt/manager/docker-compose.yml`, 10 of 12\nimages come from `registry.osism.tech`
          and exactly those two from\n`index.docker.io/library/`.\n\nDocker Hub is
          therefore a hard dependency we do not control, and it both\nreturns transient
          5xx and rate limits anonymous pulls. The task had no retry, so\none bad
          response failed the task and with it the whole manager phase.\n\nObserved
          on a fresh manager bootstrap:\n\n```\n[ERROR]: Task failed: Module failed:
          Error when processing image\nindex.docker.io/library/mariadb:11.8.8: Error
          response from daemon:\nHead \"https://registry-1.docker.io/v2/library/mariadb/manifests/11.8.8\":\nreceived
          unexpected HTTP status: 502 Bad Gateway\n```\n\nRetrying the same pull by
          hand immediately afterwards succeeded 3/3, so the\nerror was transient.\n\nWorth
          noting for anyone triaging a similar report: `docker compose pull` aborts\nevery
          image once one of them errors, so the concurrently pulling\n`registry.osism.tech`
          images were additionally reported as `Interrupted`. That\nmakes the failure
          look like a broad registry outage when it is a single image.\n\n## This
          was the only pull site without a retry\n\n| Site | Retry |\n|---|---|\n|
          `roles/netbox/tasks/service.yml` (compose pull) | `retries: 3`, `delay:
          30` |\n| `roles/netbox/tasks/restart-service.yml` (postgres, `docker_image`)
          | `retries: 3`, `delay: 30` |\n| `roles/stepca/tasks/service.yml` (compose
          pull) | `retries: 3`, `delay: 30` |\n| kolla-ansible `service-images-pull`
          | `retries`/`delay` + `until: result is success` |\n| `roles/manager/tasks/service.yml`
          | **none** |\n\nSo this reuses an established pattern rather than introducing
          one. The task is\nnow identical to the netbox sibling apart from the service
          name.\n\n## On the absent `until`\n\n`until` is omitted deliberately, to
          match the two sibling tasks. It is still\neffective, which is worth stating
          because the Ansible docs say `retries` \"is\nonly used in combination with
          `until`\":\n\n`ansible-core` computes `retries = 1 + max(0, task.retries)`
          and, when `until`\nis unset, falls back to an implicit condition on the
          task not having failed \u2014\n`cond.when = self._task.until or [not result['failed']]`
          in\n`executor/task_executor.py`. This therefore yields four attempts that
          stop as\nsoon as the pull succeeds. Verified against ansible-core 2.18,
          the series\ncurrently pinned.\n\nIf reviewers would rather be explicit,
          adding `register: result` +\n`until: result is success` here (and to the
          two siblings, for consistency) is a\nreasonable alternative \u2014 I kept
          the diff minimal instead.\n\n## Risk\n\nLow. On success the task behaves
          exactly as before. On failure it now takes up\nto 90s longer before failing
          the phase.\n\n\U0001F916 Generated with [Claude Code](https://claude.com/claude-code)\n"
        change_url: https://github.com/osism/ansible-collection-services/pull/2150
        commit_id: e7397d1e94a5612c66aa9e5308de3677ce5739e4
        patchset: e7397d1e94a5612c66aa9e5308de3677ce5739e4
        project:
          canonical_hostname: github.com
          canonical_name: github.com/osism/ansible-collection-services
          name: osism/ansible-collection-services
          short_name: ansible-collection-services
        src_dir: src/github.com/osism/ansible-collection-services
        topic: null
      change: '2150'
      change_message: "manager: retry image pull on transient errors\n\n## What\n\nAdd
        `retries: 3` / `delay: 30` to the manager role's `Pull container images`\ntask.
        Two lines, no behaviour change on the happy path.\n\n## Why\n\nThe manager
        compose file pulls two third-party images straight from Docker Hub\nby design:
        `docker_registry_service` defaults to `docker_registry`\n(`index.docker.io`),
        so `mariadb` and `redis` come from there, while the\nOSISM-built images resolve
        via `docker_registry_ansible` to\n`registry.osism.tech`. In a rendered `/opt/manager/docker-compose.yml`,
        10 of 12\nimages come from `registry.osism.tech` and exactly those two from\n`index.docker.io/library/`.\n\nDocker
        Hub is therefore a hard dependency we do not control, and it both\nreturns
        transient 5xx and rate limits anonymous pulls. The task had no retry, so\none
        bad response failed the task and with it the whole manager phase.\n\nObserved
        on a fresh manager bootstrap:\n\n```\n[ERROR]: Task failed: Module failed:
        Error when processing image\nindex.docker.io/library/mariadb:11.8.8: Error
        response from daemon:\nHead \"https://registry-1.docker.io/v2/library/mariadb/manifests/11.8.8\":\nreceived
        unexpected HTTP status: 502 Bad Gateway\n```\n\nRetrying the same pull by
        hand immediately afterwards succeeded 3/3, so the\nerror was transient.\n\nWorth
        noting for anyone triaging a similar report: `docker compose pull` aborts\nevery
        image once one of them errors, so the concurrently pulling\n`registry.osism.tech`
        images were additionally reported as `Interrupted`. That\nmakes the failure
        look like a broad registry outage when it is a single image.\n\n## This was
        the only pull site without a retry\n\n| Site | Retry |\n|---|---|\n| `roles/netbox/tasks/service.yml`
        (compose pull) | `retries: 3`, `delay: 30` |\n| `roles/netbox/tasks/restart-service.yml`
        (postgres, `docker_image`) | `retries: 3`, `delay: 30` |\n| `roles/stepca/tasks/service.yml`
        (compose pull) | `retries: 3`, `delay: 30` |\n| kolla-ansible `service-images-pull`
        | `retries`/`delay` + `until: result is success` |\n| `roles/manager/tasks/service.yml`
        | **none** |\n\nSo this reuses an established pattern rather than introducing
        one. The task is\nnow identical to the netbox sibling apart from the service
        name.\n\n## On the absent `until`\n\n`until` is omitted deliberately, to match
        the two sibling tasks. It is still\neffective, which is worth stating because
        the Ansible docs say `retries` \"is\nonly used in combination with `until`\":\n\n`ansible-core`
        computes `retries = 1 + max(0, task.retries)` and, when `until`\nis unset,
        falls back to an implicit condition on the task not having failed \u2014\n`cond.when
        = self._task.until or [not result['failed']]` in\n`executor/task_executor.py`.
        This therefore yields four attempts that stop as\nsoon as the pull succeeds.
        Verified against ansible-core 2.18, the series\ncurrently pinned.\n\nIf reviewers
        would rather be explicit, adding `register: result` +\n`until: result is success`
        here (and to the two siblings, for consistency) is a\nreasonable alternative
        \u2014 I kept the diff minimal instead.\n\n## Risk\n\nLow. On success the
        task behaves exactly as before. On failure it now takes up\nto 90s longer
        before failing the phase.\n\n\U0001F916 Generated with [Claude Code](https://claude.com/claude-code)\n"
      change_url: https://github.com/osism/ansible-collection-services/pull/2150
      child_jobs: []
      commit_id: e7397d1e94a5612c66aa9e5308de3677ce5739e4
      event_id: d9c47050-8b45-11f1-81e0-305a435ea6e8
      executor:
        hostname: 521e9411259a
        inventory_file: /var/lib/zuul/builds/4eb92f2c6c9946c68f0e8970b1f87f4f/ansible/inventory.yaml
        log_root: /var/lib/zuul/builds/4eb92f2c6c9946c68f0e8970b1f87f4f/work/logs
        result_data_file: /var/lib/zuul/builds/4eb92f2c6c9946c68f0e8970b1f87f4f/work/results.json
        src_root: /var/lib/zuul/builds/4eb92f2c6c9946c68f0e8970b1f87f4f/work/src
        work_root: /var/lib/zuul/builds/4eb92f2c6c9946c68f0e8970b1f87f4f/work
      include_vars: []
      items:
      - branch: main
        change: '2150'
        change_message: "manager: retry image pull on transient errors\n\n## What\n\nAdd
          `retries: 3` / `delay: 30` to the manager role's `Pull container images`\ntask.
          Two lines, no behaviour change on the happy path.\n\n## Why\n\nThe manager
          compose file pulls two third-party images straight from Docker Hub\nby design:
          `docker_registry_service` defaults to `docker_registry`\n(`index.docker.io`),
          so `mariadb` and `redis` come from there, while the\nOSISM-built images
          resolve via `docker_registry_ansible` to\n`registry.osism.tech`. In a rendered
          `/opt/manager/docker-compose.yml`, 10 of 12\nimages come from `registry.osism.tech`
          and exactly those two from\n`index.docker.io/library/`.\n\nDocker Hub is
          therefore a hard dependency we do not control, and it both\nreturns transient
          5xx and rate limits anonymous pulls. The task had no retry, so\none bad
          response failed the task and with it the whole manager phase.\n\nObserved
          on a fresh manager bootstrap:\n\n```\n[ERROR]: Task failed: Module failed:
          Error when processing image\nindex.docker.io/library/mariadb:11.8.8: Error
          response from daemon:\nHead \"https://registry-1.docker.io/v2/library/mariadb/manifests/11.8.8\":\nreceived
          unexpected HTTP status: 502 Bad Gateway\n```\n\nRetrying the same pull by
          hand immediately afterwards succeeded 3/3, so the\nerror was transient.\n\nWorth
          noting for anyone triaging a similar report: `docker compose pull` aborts\nevery
          image once one of them errors, so the concurrently pulling\n`registry.osism.tech`
          images were additionally reported as `Interrupted`. That\nmakes the failure
          look like a broad registry outage when it is a single image.\n\n## This
          was the only pull site without a retry\n\n| Site | Retry |\n|---|---|\n|
          `roles/netbox/tasks/service.yml` (compose pull) | `retries: 3`, `delay:
          30` |\n| `roles/netbox/tasks/restart-service.yml` (postgres, `docker_image`)
          | `retries: 3`, `delay: 30` |\n| `roles/stepca/tasks/service.yml` (compose
          pull) | `retries: 3`, `delay: 30` |\n| kolla-ansible `service-images-pull`
          | `retries`/`delay` + `until: result is success` |\n| `roles/manager/tasks/service.yml`
          | **none** |\n\nSo this reuses an established pattern rather than introducing
          one. The task is\nnow identical to the netbox sibling apart from the service
          name.\n\n## On the absent `until`\n\n`until` is omitted deliberately, to
          match the two sibling tasks. It is still\neffective, which is worth stating
          because the Ansible docs say `retries` \"is\nonly used in combination with
          `until`\":\n\n`ansible-core` computes `retries = 1 + max(0, task.retries)`
          and, when `until`\nis unset, falls back to an implicit condition on the
          task not having failed \u2014\n`cond.when = self._task.until or [not result['failed']]`
          in\n`executor/task_executor.py`. This therefore yields four attempts that
          stop as\nsoon as the pull succeeds. Verified against ansible-core 2.18,
          the series\ncurrently pinned.\n\nIf reviewers would rather be explicit,
          adding `register: result` +\n`until: result is success` here (and to the
          two siblings, for consistency) is a\nreasonable alternative \u2014 I kept
          the diff minimal instead.\n\n## Risk\n\nLow. On success the task behaves
          exactly as before. On failure it now takes up\nto 90s longer before failing
          the phase.\n\n\U0001F916 Generated with [Claude Code](https://claude.com/claude-code)\n"
        change_url: https://github.com/osism/ansible-collection-services/pull/2150
        commit_id: e7397d1e94a5612c66aa9e5308de3677ce5739e4
        patchset: e7397d1e94a5612c66aa9e5308de3677ce5739e4
        project:
          canonical_hostname: github.com
          canonical_name: github.com/osism/ansible-collection-services
          name: osism/ansible-collection-services
          short_name: ansible-collection-services
          src_dir: src/github.com/osism/ansible-collection-services
        topic: null
      job: ansible-collection-services-molecule-manager
      jobtags: []
      max_attempts: 3
      message: bWFuYWdlcjogcmV0cnkgaW1hZ2UgcHVsbCBvbiB0cmFuc2llbnQgZXJyb3JzCgojIyBXaGF0CgpBZGQgYHJldHJpZXM6IDNgIC8gYGRlbGF5OiAzMGAgdG8gdGhlIG1hbmFnZXIgcm9sZSdzIGBQdWxsIGNvbnRhaW5lciBpbWFnZXNgCnRhc2suIFR3byBsaW5lcywgbm8gYmVoYXZpb3VyIGNoYW5nZSBvbiB0aGUgaGFwcHkgcGF0aC4KCiMjIFdoeQoKVGhlIG1hbmFnZXIgY29tcG9zZSBmaWxlIHB1bGxzIHR3byB0aGlyZC1wYXJ0eSBpbWFnZXMgc3RyYWlnaHQgZnJvbSBEb2NrZXIgSHViCmJ5IGRlc2lnbjogYGRvY2tlcl9yZWdpc3RyeV9zZXJ2aWNlYCBkZWZhdWx0cyB0byBgZG9ja2VyX3JlZ2lzdHJ5YAooYGluZGV4LmRvY2tlci5pb2ApLCBzbyBgbWFyaWFkYmAgYW5kIGByZWRpc2AgY29tZSBmcm9tIHRoZXJlLCB3aGlsZSB0aGUKT1NJU00tYnVpbHQgaW1hZ2VzIHJlc29sdmUgdmlhIGBkb2NrZXJfcmVnaXN0cnlfYW5zaWJsZWAgdG8KYHJlZ2lzdHJ5Lm9zaXNtLnRlY2hgLiBJbiBhIHJlbmRlcmVkIGAvb3B0L21hbmFnZXIvZG9ja2VyLWNvbXBvc2UueW1sYCwgMTAgb2YgMTIKaW1hZ2VzIGNvbWUgZnJvbSBgcmVnaXN0cnkub3Npc20udGVjaGAgYW5kIGV4YWN0bHkgdGhvc2UgdHdvIGZyb20KYGluZGV4LmRvY2tlci5pby9saWJyYXJ5L2AuCgpEb2NrZXIgSHViIGlzIHRoZXJlZm9yZSBhIGhhcmQgZGVwZW5kZW5jeSB3ZSBkbyBub3QgY29udHJvbCwgYW5kIGl0IGJvdGgKcmV0dXJucyB0cmFuc2llbnQgNXh4IGFuZCByYXRlIGxpbWl0cyBhbm9ueW1vdXMgcHVsbHMuIFRoZSB0YXNrIGhhZCBubyByZXRyeSwgc28Kb25lIGJhZCByZXNwb25zZSBmYWlsZWQgdGhlIHRhc2sgYW5kIHdpdGggaXQgdGhlIHdob2xlIG1hbmFnZXIgcGhhc2UuCgpPYnNlcnZlZCBvbiBhIGZyZXNoIG1hbmFnZXIgYm9vdHN0cmFwOgoKYGBgCltFUlJPUl06IFRhc2sgZmFpbGVkOiBNb2R1bGUgZmFpbGVkOiBFcnJvciB3aGVuIHByb2Nlc3NpbmcgaW1hZ2UKaW5kZXguZG9ja2VyLmlvL2xpYnJhcnkvbWFyaWFkYjoxMS44Ljg6IEVycm9yIHJlc3BvbnNlIGZyb20gZGFlbW9uOgpIZWFkICJodHRwczovL3JlZ2lzdHJ5LTEuZG9ja2VyLmlvL3YyL2xpYnJhcnkvbWFyaWFkYi9tYW5pZmVzdHMvMTEuOC44IjoKcmVjZWl2ZWQgdW5leHBlY3RlZCBIVFRQIHN0YXR1czogNTAyIEJhZCBHYXRld2F5CmBgYAoKUmV0cnlpbmcgdGhlIHNhbWUgcHVsbCBieSBoYW5kIGltbWVkaWF0ZWx5IGFmdGVyd2FyZHMgc3VjY2VlZGVkIDMvMywgc28gdGhlCmVycm9yIHdhcyB0cmFuc2llbnQuCgpXb3J0aCBub3RpbmcgZm9yIGFueW9uZSB0cmlhZ2luZyBhIHNpbWlsYXIgcmVwb3J0OiBgZG9ja2VyIGNvbXBvc2UgcHVsbGAgYWJvcnRzCmV2ZXJ5IGltYWdlIG9uY2Ugb25lIG9mIHRoZW0gZXJyb3JzLCBzbyB0aGUgY29uY3VycmVudGx5IHB1bGxpbmcKYHJlZ2lzdHJ5Lm9zaXNtLnRlY2hgIGltYWdlcyB3ZXJlIGFkZGl0aW9uYWxseSByZXBvcnRlZCBhcyBgSW50ZXJydXB0ZWRgLiBUaGF0Cm1ha2VzIHRoZSBmYWlsdXJlIGxvb2sgbGlrZSBhIGJyb2FkIHJlZ2lzdHJ5IG91dGFnZSB3aGVuIGl0IGlzIGEgc2luZ2xlIGltYWdlLgoKIyMgVGhpcyB3YXMgdGhlIG9ubHkgcHVsbCBzaXRlIHdpdGhvdXQgYSByZXRyeQoKfCBTaXRlIHwgUmV0cnkgfAp8LS0tfC0tLXwKfCBgcm9sZXMvbmV0Ym94L3Rhc2tzL3NlcnZpY2UueW1sYCAoY29tcG9zZSBwdWxsKSB8IGByZXRyaWVzOiAzYCwgYGRlbGF5OiAzMGAgfAp8IGByb2xlcy9uZXRib3gvdGFza3MvcmVzdGFydC1zZXJ2aWNlLnltbGAgKHBvc3RncmVzLCBgZG9ja2VyX2ltYWdlYCkgfCBgcmV0cmllczogM2AsIGBkZWxheTogMzBgIHwKfCBgcm9sZXMvc3RlcGNhL3Rhc2tzL3NlcnZpY2UueW1sYCAoY29tcG9zZSBwdWxsKSB8IGByZXRyaWVzOiAzYCwgYGRlbGF5OiAzMGAgfAp8IGtvbGxhLWFuc2libGUgYHNlcnZpY2UtaW1hZ2VzLXB1bGxgIHwgYHJldHJpZXNgL2BkZWxheWAgKyBgdW50aWw6IHJlc3VsdCBpcyBzdWNjZXNzYCB8CnwgYHJvbGVzL21hbmFnZXIvdGFza3Mvc2VydmljZS55bWxgIHwgKipub25lKiogfAoKU28gdGhpcyByZXVzZXMgYW4gZXN0YWJsaXNoZWQgcGF0dGVybiByYXRoZXIgdGhhbiBpbnRyb2R1Y2luZyBvbmUuIFRoZSB0YXNrIGlzCm5vdyBpZGVudGljYWwgdG8gdGhlIG5ldGJveCBzaWJsaW5nIGFwYXJ0IGZyb20gdGhlIHNlcnZpY2UgbmFtZS4KCiMjIE9uIHRoZSBhYnNlbnQgYHVudGlsYAoKYHVudGlsYCBpcyBvbWl0dGVkIGRlbGliZXJhdGVseSwgdG8gbWF0Y2ggdGhlIHR3byBzaWJsaW5nIHRhc2tzLiBJdCBpcyBzdGlsbAplZmZlY3RpdmUsIHdoaWNoIGlzIHdvcnRoIHN0YXRpbmcgYmVjYXVzZSB0aGUgQW5zaWJsZSBkb2NzIHNheSBgcmV0cmllc2AgImlzCm9ubHkgdXNlZCBpbiBjb21iaW5hdGlvbiB3aXRoIGB1bnRpbGAiOgoKYGFuc2libGUtY29yZWAgY29tcHV0ZXMgYHJldHJpZXMgPSAxICsgbWF4KDAsIHRhc2sucmV0cmllcylgIGFuZCwgd2hlbiBgdW50aWxgCmlzIHVuc2V0LCBmYWxscyBiYWNrIHRvIGFuIGltcGxpY2l0IGNvbmRpdGlvbiBvbiB0aGUgdGFzayBub3QgaGF2aW5nIGZhaWxlZCDigJQKYGNvbmQud2hlbiA9IHNlbGYuX3Rhc2sudW50aWwgb3IgW25vdCByZXN1bHRbJ2ZhaWxlZCddXWAgaW4KYGV4ZWN1dG9yL3Rhc2tfZXhlY3V0b3IucHlgLiBUaGlzIHRoZXJlZm9yZSB5aWVsZHMgZm91ciBhdHRlbXB0cyB0aGF0IHN0b3AgYXMKc29vbiBhcyB0aGUgcHVsbCBzdWNjZWVkcy4gVmVyaWZpZWQgYWdhaW5zdCBhbnNpYmxlLWNvcmUgMi4xOCwgdGhlIHNlcmllcwpjdXJyZW50bHkgcGlubmVkLgoKSWYgcmV2aWV3ZXJzIHdvdWxkIHJhdGhlciBiZSBleHBsaWNpdCwgYWRkaW5nIGByZWdpc3RlcjogcmVzdWx0YCArCmB1bnRpbDogcmVzdWx0IGlzIHN1Y2Nlc3NgIGhlcmUgKGFuZCB0byB0aGUgdHdvIHNpYmxpbmdzLCBmb3IgY29uc2lzdGVuY3kpIGlzIGEKcmVhc29uYWJsZSBhbHRlcm5hdGl2ZSDigJQgSSBrZXB0IHRoZSBkaWZmIG1pbmltYWwgaW5zdGVhZC4KCiMjIFJpc2sKCkxvdy4gT24gc3VjY2VzcyB0aGUgdGFzayBiZWhhdmVzIGV4YWN0bHkgYXMgYmVmb3JlLiBPbiBmYWlsdXJlIGl0IG5vdyB0YWtlcyB1cAp0byA5MHMgbG9uZ2VyIGJlZm9yZSBmYWlsaW5nIHRoZSBwaGFzZS4KCvCfpJYgR2VuZXJhdGVkIHdpdGggW0NsYXVkZSBDb2RlXShodHRwczovL2NsYXVkZS5jb20vY2xhdWRlLWNvZGUpCg==
      patchset: e7397d1e94a5612c66aa9e5308de3677ce5739e4
      pipeline: check
      playbook_context:
        playbook_projects:
          trusted/project_0/github.com/osism/zuul-config:
            canonical_name: github.com/osism/zuul-config
            checkout: main
            commit: 71b711c422c10c242a8f785dc6d41ed9d12e9cd3
          trusted/project_1/github.com/osism/openinfra-zuul-jobs:
            canonical_name: github.com/osism/openinfra-zuul-jobs
            checkout: master
            commit: 242732586e2cba04d04867d3e302888c766bc231
          trusted/project_2/github.com/osism/zuul-jobs:
            canonical_name: github.com/osism/zuul-jobs
            checkout: main
            commit: dcb06ea8a3ad422cc9d98b376216617b2daa6a02
          untrusted/project_0/github.com/osism/zuul-jobs:
            canonical_name: github.com/osism/zuul-jobs
            checkout: main
            commit: dcb06ea8a3ad422cc9d98b376216617b2daa6a02
          untrusted/project_1/github.com/osism/zuul-config:
            canonical_name: github.com/osism/zuul-config
            checkout: main
            commit: 71b711c422c10c242a8f785dc6d41ed9d12e9cd3
          untrusted/project_2/github.com/osism/openinfra-zuul-jobs:
            canonical_name: github.com/osism/openinfra-zuul-jobs
            checkout: master
            commit: 242732586e2cba04d04867d3e302888c766bc231
        playbooks:
        - path: untrusted/project_0/github.com/osism/zuul-jobs/playbooks/ansible-molecule/run.yaml
          roles:
          - checkout: main
            checkout_description: zuul branch
            link_name: ansible/playbook_0/role_0/zuul-config
            link_target: untrusted/project_1/github.com/osism/zuul-config
            role_path: ansible/playbook_0/role_0/zuul-config/roles
          - checkout: master
            checkout_description: project default branch
            link_name: ansible/playbook_0/role_1/openinfra-zuul-jobs
            link_target: untrusted/project_2/github.com/osism/openinfra-zuul-jobs
            role_path: ansible/playbook_0/role_1/openinfra-zuul-jobs/roles
          - checkout: main
            checkout_description: playbook branch
            link_name: ansible/playbook_0/role_2/zuul-jobs
            link_target: untrusted/project_0/github.com/osism/zuul-jobs
            role_path: ansible/playbook_0/role_2/zuul-jobs/roles
      post_review: false
      post_timeout: 1800
      pre_timeout: null
      project:
        canonical_hostname: github.com
        canonical_name: github.com/osism/ansible-collection-services
        name: osism/ansible-collection-services
        short_name: ansible-collection-services
        src_dir: src/github.com/osism/ansible-collection-services
      projects:
        github.com/osism/ansible-collection-services:
          canonical_hostname: github.com
          canonical_name: github.com/osism/ansible-collection-services
          checkout: main
          checkout_description: zuul branch
          commit: 4c59a44ee5078dd2e8b5d4863de77d1414d35509
          name: osism/ansible-collection-services
          required: false
          short_name: ansible-collection-services
          src_dir: src/github.com/osism/ansible-collection-services
      ref: refs/pull/2150/head
      resources: {}
      tenant: osism
      timeout: 1800
      topic: null
      voting: true
