This module gathers facts from a VMWare vSphere guest by querying vSphere. The facts include OS, network info (vlan, macaddress) and system info (cpu, memory, uuid) information. Useful information for provisioning and management.
This module gathers facts from the hardware interface by querying HP iLO. The facts include network info (vlan, macaddress) and system info (cpu, memory, uuid) information. Useful information for provisioning and management.
This module was previously named ilo_facts and mentioned in #1080, #1085, #1125 and #1217.
After helping someone on IRC he was interested to have this debug module in upstream. This module simply 'prints' a message, and can be ordered to fail if needed. It helps to troubleshoot or understand inventory/facts issues and/or experiment with statements and conditions using only_if.
Here is a small example playbook:
```yaml
- hosts: all
tasks:
- local_action: debug msg="System $inventory_hostname has uuid ${ansible_product_uuid}"
- local_action: debug msg="System $inventory_hostname lacks a gateway" fail=yes
only_if: "is_unset('$ansible_default_ipv4.gateway')"
- local_action: debug msg="System $inventory_hostname has gateway ${ansible_default_ipv4.gateway}"
only_if: "is_set('$ansible_default_ipv4.gateway')"
```
outputting:
```
[root@moria ansible]# ansible-playbook -v -l localhost:x220 test6.yml
PLAY [all] *********************
GATHERING FACTS *********************
ok: [localhost]
ok: [x220]
TASK: [debug msg="System $inventory_hostname has uuid $ansible_product_uuid"] *********************
ok: [localhost] => {"msg": "System localhost has uuid d125a48c-364f-4e65-b225-fed42ed61fac"}
ok: [x220] => {"msg": "System x220 has uuid d125a48c-364f-4e65-b225-fed42ed61fac"}
TASK: [debug msg="System $inventory_hostname lacks a gateway" fail=yes] *********************
failed: [localhost] => {"failed": true, "msg": "System localhost lacks a gateway", "rc": 1}
ok: [x220] => {"msg": "System x220 has gateway 192.168.1.1"}
PLAY RECAP *********************
localhost : ok=2 changed=0 unreachable=0 failed=1
x220 : ok=3 changed=0 unreachable=0 failed=0
```
I had some other plans for the module, like displaying host inventory and complete inventory to help understand inventory and facts modules, but that would require an action-plugin for transfering inventory information etc... And I am not sure this is wanted/best done in a module.
We now check explicitely for 'module_setup' in the SETUP_CACHE in order to avoid skipping setup because SETUP_CACHE was populated some other way. Other modules can implement the same mechanism to test if they've already run.
This closes#1206.
Since a skipped/ignored action is _very_ different from actual changes to a system, it always bothered me that it was not easily distinguishable when skimming the output. This change makes ignore/skip a different color, and I chose cyan. Contemplated using dark-gray/blue, but prefered something that is readable with most terminal colors.
In some cases you may want to deliberately fail the execution of a playbook. In our provisioning workflow we want to have safeguards in place to avoid provisioning systems that are already in production. Since we reboot physical and virtual systems, it is mandatory we take all the precautions to prevent accidental provisioning.
So in our use-case we have the following at the very start of the provisioning playbook:
### Safeguard to protect production systems
- local_action: fail msg="System is not ready to be staged according to CMDB"
only_if: "'$cmdb_status' != 'to-be-staged'"
and we repeat the same task in the (separate included) play that takes care of (re)booting the system using our own boot-media, so that it cannot be accidentally separately run by someone.
