Problem:
Not really a problem, more a question We are no longer using puppet in managing our clients, only Ansible. The facts are populated when the host is deployed, no issues there. However, Puppet seemed to to some sort of âcheck inâ every couple of hours (days?) and update the host facts. Ansible doesnât seem to do that. Do I need to schedule an âansible setupâ job to simulate that? As all our hosts show no facts and a âlast reportâ of the deployment date since the last ansible run.
Expected outcome:
Update the facts through ansible periodically and set âlast reportâ to that time.
Do I need to schedule an âansible setupâ job to simulate that?
That could be the way, you can set up recurring execution of the job as you like (daily, hourly) and run some really simple playbook, I use for example this one:
Thank you @lstejska, I executed a job with the minimum playbook and the facts are updated fine.
However, the hosts are still all listed as âLast Reportâ of months ago and âOut of sync 100%â. I think I am missing something here. The only warning I see when executing the run book is:
[DEPRECATION WARNING]: [defaults]callback_whitelist option, normalizing names
to new standard, use callbacks_enabled instead. This feature will be removed
from ansible-core in version 2.15. Deprecation warnings can be disabled by
setting deprecation_warnings=False in ansible.cfg.
[WARNING]: Callback disabled by environment. Disabling the Foreman callback
plugin.
Not sure if this could have anything to do with sending reports back to Foreman.
Thatâs an issue, itâs clearly saying that callbacks are disabled, so I would check again if facts really have been updated. On my setup running the playbook updates facts and also the last report time.
I ran my ansible playbook with debug logging and found this at the top of the output:
ansible-playbook [core 2.13.3]
config file = /usr/share/foreman-proxy/.ansible.cfg
configured module search path = ['/usr/share/foreman-proxy/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
ansible python module location = /usr/lib/python3.9/site-packages/ansible
ansible collection location = /etc/ansible/collections:/usr/share/ansible/collections
executable location = /usr/bin/ansible-playbook
python version = 3.9.13 (main, Nov 8 2022, 17:21:43) [GCC 8.5.0 20210514 (Red Hat 8.5.0-15)]
jinja version = 3.1.2
libyaml = False
Using /usr/share/foreman-proxy/.ansible.cfg as config file
[DEPRECATION WARNING]: [defaults]callback_whitelist option, normalizing names
to new standard, use callbacks_enabled instead. This feature will be removed
from ansible-core in version 2.15. Deprecation warnings can be disabled by
setting deprecation_warnings=False in ansible.cfg.
setting up inventory plugins
host_list declined parsing /tmp/d20221207-1196-589gnc/inventory/hosts as it did not pass its verify_file() method
Parsed /tmp/d20221207-1196-589gnc/inventory/hosts inventory source with script plugin
Loading callback plugin awx_display of type stdout, v2.0 from /usr/lib/python3.6/site-packages/ansible_runner/callbacks/awx_display.py
Loading collection theforeman.foreman from /usr/share/ansible/collections/ansible_collections/theforeman/foreman
Skipping callback 'awx_display', as we already have a stdout callback.
Skipping callback 'default', as we already have a stdout callback.
Skipping callback 'minimal', as we already have a stdout callback.
Skipping callback 'oneline', as we already have a stdout callback.
Loading callback plugin theforeman.foreman.foreman of type notification, v2.0 from /usr/share/ansible/collections/ansible_collections/theforeman/foreman/plugins/callback/foreman.py
[WARNING]: Callback disabled by environment. Disabling the Foreman callback
plugin.
Checking the ansible config file /usr/share/foreman-proxy/.ansible.cfg, which seems to be maintained by Foreman:
seems to be fine, as the (even though deprecated) whitelist parameter is set and you can also see in the log above, the the plugin gets loaded.
According to this pull request on the callback plugin:
the ability was introduced for the callback plugin to be disabled on a case by case basis. For that it checks the environment variable FOREMAN_CALLBACK_DISABLE, which I cannot find set anywhere. The default of this should be 0, meaning activated.
But the warning message clearly indicates, that this environment variable was either set to 1 or the default check doesnât work.
Well, then that behaviour is expected, not sure why and how it works for lstejskal. Facts are only uploaded for the job template which has the ansible_run_host feature assigned to it. By default, the job template to apply assigned roles has this feature assigned. This will probably change in the foreseeable future, but right now this is what we have
Oh I see, havenât been aware of that so far. Thank you for the clarification.
Is it possible to define a new job template with the ansible_run_host feature assigned and use it to collect facts? To me it looks like this is an internal setting as I canât find the feature list exposed at the job template âAnsible Roles - Ansible Defaultâ.
You can reassign the feature to a different job template in Administer > Remote execution features but currently it can be assigned to only one template at a time
Understood, thank you @aruzicka. In that case I would need to wait until multiple templates can produce facts for Ansible. I will raise a redmine feature request for it, if there isnât already one.
We are no longer using puppet in managing our clients, only Ansible. The facts are populated when the host is deployed, no issues there. However, Puppet seemed to to some sort of âcheck inâ every couple of hours (days?) and update the host facts. Ansible doesnât seem to do that. Do I need to schedule an âansible setupâ job to simulate that? As all our hosts show no facts and a âlast reportâ of the deployment date since the last ansible run.