Ansible Cant find Debian Apt Package for Multi Playbook/Tasks Runs with Galaxy FreeIPA Install

I have a single node deployment anisble playbook that runs via rundeck to stage cloud-init, pxe installed, 20.04 Ubuntu systems with ubuntu desktop for an idm domain with a standard configuration. The issue I am having is that on first run after the pxe process we get a “No package matching ‘freeipa-client’ is available” when we get into installing the free-ipa client via galaxy ansible_freeipa on the host.

If we run a repeat rundeck job almost immediately after the first failure, we get a “Could not get lock /var/lib/dpkg/lock-frontend. It is held by process XXXXX (apt)” or sometimes depending on some troubleshooting steps that were tried, apt-get. Then once we wait for a “time” we do a third run and it will finish correctly. I have told it to do manual apt-get based updates also which caused the same type of errors in other parts of the play and one time it errored out an a pre bash script with the lock and error-ed out one time saying it couldn’t find “crony” under another step.

Based on multiple tests, I believe this is an issue related to ansible not waiting for apt/apt-get to completely finish before continuing on.

Is there some sort of strategy I am missing for the playbook or free-ipa role for it to not be handling the plays correctly for apt/apt-get causing this sort of problem?

It occurs inside the primary playbook and the subsequent call of the galaxy free-ipa playbook but usually between steps “TASK [ipaclient : Import variables specific to distribution]” and “TASK [ipaclient : Install IPA client]” within the free_ipa cliient task call.

I have looked into potentially implementing a wait_for but that doesn’t really make sense as the galaxy call is just that, an import install call and not something I necessarily would be adjusting without messing with the base project. I am unsure if this is strictly an ansible problem or potentially a galaxy free_ipa problem in the way it is using ansible.

Any thoughts on this would be greatly appreciated.

Maybe it's not the most clean approach, but you can check if the
command returned an error message including "Could not get lock"
substring.

You can repeat this command with some delay in between and with a
limit of repeating cycles, waiting for the automatic update to finish.
Once the command ends with no error (or with a different error), then
you can continue.

I have seen that strategy also but as you say, not super clean. I may have to go digging into the ansible galaxy roles and see if I can do some tweaking there because that appears to be the primary area with the issue. Outside of that a wait strategy might work.