infra.ah_configuration.publish fails to publish more than one collection

[myllynen]

With a local automation hub and collection version 2.0.4 using the following with the needed namespace created earlier the publish role fails with a permission denied message:

ah_collections:
  - collection_name: myllynen.rhel_ansible_roles
    git_url: https://github.com/myllynen/rhel-ansible-roles
    version: v1.4.11

  - collection_name: myllynen.rhel_image
    git_url: https://github.com/myllynen/rhel-image
    version: v1.1.3

    msg: You don't have permission to GET
        to /api/galaxy/content/staging/v3/plugin/ansible/imports/collections/<uuid>/
        (HTTP 403).

If I run the role with either one commented out then the role works. However, then every second playbook run fails with the "Collection .. exists" error even with ah_auto_approve set to true. In my tests I've restored all the AAP 2.4 VMs from snapshots created after installation so previous runs or leftovers in /var/tmp are not affecting my tests.

Thanks.

[djdanielsson]

I think the issue is timing, I do not believe hub has time to show the content in staging before the check runs which is why you get an error... I thought we added a timeout for this but I have been away for a while and don't remember anymore. If you could test adding some wait time to see if that is the issue that would be helpful.

[myllynen]

Thanks for looking into this.

Adding "pause: 1" for the loop in the task "Publish Collections" or setting ah_request_timeout to 1 allows publishing more than one collection, so then the example configuration shared in the initial comment works.

The second run of the playbook still fails with this, increasing the timeout doesn't seem to help with that.

[djdanielsson]

correct, we could look into adding an API check to see if that exact collection version is already there before trying anything to then skip to make it more idempotent. but currently we are trying to improve other functionality currently.

[myllynen]

FWIW, I think this the only real issue preventing fully GitOps based PAH management. After the initial installation and population of the hub, typical day 2 tasks would be mostly occasional collection and EE updates but due to this issue the process for above kind of collections more or less has to be manual as otherwise the update most likely fails. Thanks.

[dbk-rabel]

I just realised: Could this just be same issue as #380 ? And therefore fixed by #386 ?

[Tompage1994]

I just realised: Could this just be same issue as #380 ? And therefore fixed by #386 ?

I would be pretty shocked if this is not not fixed as the error seems to be the exact same. I'm going to close this but if anyone discovers it's still an issue in the latest version please feel free to re-open

[myllynen]

I'm happy to confirm that PR 386 fixed this issue!

After that I ran another issue so I filed #397 for that.

Thanks.