I had made and pushed this change after you already pulled the request.
@dhozac indicated that it would probably be better to use return codes > 255 for anything related to Ansible itself. Which makes sens :)
We use the lineinfile module to modify configuration files of a proprietary application. This application reads configuration options from files, but does not require those files to exist (if the default options are fine). However this application may modify the configuration file at will, so we cannot copy or template those files. And after a silent install the configuration may not exist (depending on the response file).
Whatever the case, during deployment we need to make sure some configuration options are set after the installation.
So the cleanest way to handle this situation is to allow the lineinfile module to create the file if it is missing (and this is the expected behavior). When I proposed this behavior, @sergevanginderachter needed the same functionality and was now working around it as well.
I had made and pushed this change after you already pulled the request.
@dhozac indicated that it would probably be better to use return codes > 255 for anything related to Ansible itself. Which makes sens :)
Split module into a main calling function, and a generic
(Linux useradd/usermod/userdel) User class.
Added a __new__ function that selects most appropriate superclass
Added a FreeBSD User class
Tested against FreeBSD 9.0
If this is not a certainty, playbooks will fail without an 'rc' and checking both if there is an rc, and whether the 'rc' is (not) 0 is very complicated. (especially because ${something.rc} will not be substituted and all that)
Detect when on a 'no branch' branch. If so, checkout the HEAD branch
as reported by 'git remote show <remote>'. That should put the repo
back on a branch such that git can then merge changes as necessary.
In addition, removed hard-coded references to origin and replaced
with remote var.
This allows one to create a SSH key for user. You may define:
ssh_key_type, ssh_key_bits, ssh_key_file, ssh_key_comment,
and ssh_key_passphrase. If no passphrase is provided, the
key will be passphrase-less. This will not overwrite an existing key.
In the JSON returned, it will provide the ssh_fingerprint and
ssh_key_file.
- fixed template (it was the template), adding indentation with Jinja2
- added description of code examples to man-page template (was missing)
- fixed fireball, cron, and debug module examples to confrom
On Red Hat, CentOS and Fedora systems, the pip binary will be called python-pip
instead of pip. This commit makes the pip module also check for python-pip.
The reason we check for python-pip *first*, is to have ansible fail on not
finding 'pip' and reporting *that*. This is consistent with current behaviour
and will not confuse users of Debian et al., where the 'python-pip' binary
never exists.
Tested on Fedora 18 and Ubuntu 12.04.
This commit improves the following items:
- Remove the 'match' functionality, this can now be achieve by using the `fail` module together with `only_if` after running the `hpilo_facts` module. Since this gives more functionality, e.g. comparing server names, but also serial numbers or uuids with other inventory information, this is prefered. An example is added to show how this is achieved.
- Clean up all C() calls in documentation
- Added state=poweroff in order to power off a server. The use-case is here that in general we do not want to provision systems that are already running (this enforcement can be disabled using force=yes) but for test systems we should be able to power them off so we can start the normal provisioning process. (We could also force boot them, but that's less elegant)
- The module now correctly indicates when something has changed. So if a server is powered off that was not off already, this is indicated, or when media boot-settings have been changed, this is also correctly indicated. Previously every call to hpilo_boot was (incorrectly) considered a change.
This commit improves the following items:
- Remove the 'match' functionality, this can now be achieve by using the `fail` module together with `only_if` after running the `hpilo_facts` module. Since this gives more functionality, e.g. comparing server names, but also serial numbers or uuids with other inventory information **and** a proper message, this is prefered. An example is added to show how this is achieved.
- Clean up all C() calls in documentation
- Remove trailing spaces in HP iLO's Serial Number output so that they can be compared to CMDB or other inventory information
Sending mails could be part of the workflow to have teams/responsibles perform specific task. Or simply to notify that a process has finished successfully (e.g. provisioning).
This workaround is recommended from HP iLO's documentation, but may not be sufficient in all cases. Time will tell.
I also made a few cosmetic changes with no impact.
Much like we currently have *setup* register the variable `module_setup`, we would like other facts-modules register their own namespace. This means that:
- *network_facts* registers `module_network`
- *hpilo_facts* registers `module_hw`
- *vsphere_facts* registers `module_hw`
In retrospect, it would have made more sense to have `setup` register `module_ansible` instead as the setup module uses the `ansible_` namesepace.
Having the `module_` namespace allows us to check whether a certain namespace has already been loaded so we can avoid running the facts module a second time using only_if.
```yaml
- action: network_facts host=${ansible_hostname_short}
only_if: is_unset('$module_network')
```
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.
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.
