* Support 'termination protection' for cloudformation stacks
- Pass in the stack_name and desired termination protection state to update_termination_protection
* Fix for failing cloudformation unit test
* Check if cfn has update_termination_protection attr
* Use hasattr to test if cfn supports update_termination_protection
* termination_protection shouldn't prevent update_stack call for existing stacks
in ServiceNow
Remove "updated" as a option for state, per review from bcoca. Update
examples section, and tested.
Update metadata to 1.1
Rip out some more instances of updated from documentation.
Update for ansible 2.5 first version
* better cleanup on task results display
callbacks get 'clean' copy of result objects
moved cleanup into result object itself
removed now redundant callback cleanup
moved no_log tests
* moved import as per feedback
- added `role_arn` to the "role example" example
- removed the irrelevant parameters to the "role example" example
- updated comment on one of the examples
- removed the last example as it was a duplicate of "role example" example
- some other minor changes
In this refactor we moved to the most recent coding standards for
both F5 and Ansible. Many bugs were fixed and some features were
also added (such as ipv6 support).
New conventions for ansible warrant fixes to accomodate those
in bigip_partition.
This patch also includes an import fix that can raise an error when
Ansible unit tests run
This adds a new type of vault-password script (a 'client') that takes advantage of and enhances the
multiple vault password support.
If a vault password script basename ends with the name '-client', consider it a vault password script client.
A vault password script 'client' just means that the script will take a '--vault-id' command line arg.
The previous vault password script (as invoked by --vault-password-file pointing to an executable) takes
no args and returns the password on stdout. But it doesnt know anything about --vault-id or multiple vault
passwords.
The new 'protocol' of the vault password script takes a cli arg ('--vault-id') so that it can lookup that specific
vault-id and return it's password.
Since existing vault password scripts don't know the new 'protocol', a way to distinguish password scripts
that do understand the protocol was needed. The convention now is to consider password scripts that are
named like 'something-client.py' (and executable) to be vault password client scripts.
The new client scripts get invoked with the '--vault-id' they were requested for. An example:
ansible-playbook --vault-id my_vault_id@contrib/vault/vault-keyring-client.py some_playbook.yml
That will cause the 'contrib/vault/vault-keyring-client.py' script to be invoked as:
contrib/vault/vault-keyring-client.py --vault-id my_vault_id
The previous vault-keyring.py password script was extended to become vault-keyring-client.py. It uses
the python 'keyring' module to request secrets from various backends. The plain 'vault-keyring.py' script
would determine which key id and keyring name to use based on values that had to be set in ansible.cfg.
So it was also limited to one keyring name.
The new vault-keyring-client.py will request the secret for the vault id provided via the '--vault-id' option.
The script can be used without config and can be used for multiple keyring ids (and keyrings).
On success, a vault password client script will print the password to stdout and exit with a return code of 0.
If the 'client' script can't find a secret for the --vault-id, the script will exit with return code of 2 and print an error to stderr.
