I was trying to use the UU Provisioning component for all common tasks, including:
installing security updates
places messages in motd, etc.
However, it turns out that when we use the security_updates role in a playbook that also contains further roles, these further roles throw errors. For instance, fact_regular_users was throwing this error:
fatal: [localhost]: FAILED! => {\"msg\": \"You need to install \\\"jmespath\\\" prior to running json_query filter\"}
...despite the fact that the role does install jmespath first.
Similarly, fact_workspace_info was throwing errors about the fact that python3-apt was not installed, when in fact it is.
My hypothesis is that the installation of the security updates is still going on when the next role is called, and that the lock on the apt database is causing ansible modules to fail, which is mistakenly being interpreted as the absence of a required dependency.
For now I've disabled security updates in UU Provisioning (we can still use the separate Security Updates component).
I was trying to use the UU Provisioning component for all common tasks, including:
However, it turns out that when we use the
security_updatesrole in a playbook that also contains further roles, these further roles throw errors. For instance,fact_regular_userswas throwing this error:...despite the fact that the role does install
jmespathfirst.Similarly,
fact_workspace_infowas throwing errors about the fact thatpython3-aptwas not installed, when in fact it is.My hypothesis is that the installation of the security updates is still going on when the next role is called, and that the lock on the apt database is causing ansible modules to fail, which is mistakenly being interpreted as the absence of a required dependency.
For now I've disabled security updates in UU Provisioning (we can still use the separate Security Updates component).