Uploaded image for project: 'Ansible Automation Platform RFEs'
  1. Ansible Automation Platform RFEs
  2. AAPRFE-1015

Let execution node use existing EE image when podman pull fails under the ALWAYS PULL policy

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Won't Do
    • Icon: Normal Normal
    • None
    • 2.4, 2.5
    • controller
    • False
    • Hide

      None

      Show
      None
    • False

      1. What is the nature and description of the request?
        When an execution node wants to use an EE whose pull policy is "Always pull", and the following conditions are met:
      • the `podman pull` command fails for any reason, and
      • the execution node already has some version of the EE image stored locally,
        THEN: a failure to `podman pull` should be worked around and the container should run with the existing version.
        A clear WARNING should still be issued in case of `podman pull` failures so this doesn't become a silent failure. But `podman pull` failures should not prevent jobs from running if possible.
      1. Why does the customer need this? (List the business requirements here)
        The `podman pull` command may fail for a number of reasons, from networking issues to Private Automation Hub misconfiguration. EE images with a policy of "always pull" will often detect that there's no change in the image so nothing will be really pulled. Occasional failures to `podman pull` should definitely be investigated by AAP and PAH admins, but they should not prevent an otherwise perfectly healthy AAP from running jobs.
      2. How would you like to achieve this? (List the functional requirements here)
        Create a new download policy named "try to pull" that is a variant of "always pull": it will always attempt to `podman pull` the image and will use an existing local version of the EE image if `podman pull` fails and a local image exists.
      3. List any affected known dependencies: Doc, UI etc..
        Doc, UI, API.

              bcoursen@redhat.com Brian Coursen
              phess@redhat.com Pablo Hess
              Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: