* Update module_utils.six to latest
We've been held back on the version of six we could use on the module
side to 1.4.x because of python-2.4 compatibility. Now that our minimum
is Python-2.6, we can update to the latest version of six in
module_utils and get rid of the second copy in lib/ansible/compat.
Made ansible-doc more plugin agnostic
We can have docs in lookup, callback, connectionm strategy, etc
Use first docstring and make pepizis happy
generalized module_docs to plugin_docs
documented cartesian, ssh, default, jsonfile, etc as examples
changed lack of docs to warning when listing
made smarter about bad docstrings
better blacklisting
added handling of options/config/envs/etc
move blacklist to find_plugins, only need once
Changes to the metadata format were approved here:
https://github.com/ansible/proposals/issues/54
* Update documentation to the new metadata format
* Changes to metadata-tool to account for new metadata
* Add GPL license header
* Add upgrade subcommand to upgrade metadata version
* Change default metadata to the new format
* Fix exclusion of non-modules from the metadata report
* Fix ansible-doc for new module metadata
* Exclude metadata version from ansible-doc output
* Fix website docs generation for the new metadata
* Update metadata schema in valiate-modules test
* Update the metadata in all modules to the new version
* Retain vault password as bytes in 2.2
Prior to 2.2.1, the vault password was read in as byes and then remained
bytes all the way through the code. A bug existed where bytes and text
were mixed, leading to a traceback with non-ascii passwords. In devel,
this was fixed by changing the read in password to text type to match
with our overall strategy of converting at the borders. This was
backported to stable-2.2 for the 2.2.1 release.
On reflection, this should not have been backported as it causes
passwords which were originally non-utf-8 to become utf-8. People will
then have their working 2.2.x vault files become in-accessible.
this commit pipes bytes all the way through the system for vault
password. That way if a password is read in as a non-utf-8 character
sequence, it will continue to work in 2.2.2+. This change is only for
the 2.2 branch, not for 2.3 and beyond.
Why not everywhere? The reason is that non-utf-8 passwords will cause
problems when vault files are shared between systems or users. If the
password is read from the prompt and one user/machine has a latin1
encoded locale while a second one has utf-8, the non-ascii password
typed in won't match between machines. Deal with this by making sure
that when we encrypt the data, we always use valid utf-8.
Fixes#20398
(cherry picked from commit 5dcce0666a)
* Add role skeleton support
The default role skeleton used by ansible-galaxy is good, but it doesn't
allow organizations to customize it to suit their needs. This patch
addresses that by adding the option to point ansible-galaxy at a
role skeleton directory. The contents of this directory are then
copied (or rendered) into the output role directory. Appropriate
command line options and configuration entries are added to allow for
further customization from the role skeleton.
* Remove dependency on platforms list from test
Platforms are no longer provided to the template by galaxy init.
Removing the code in our test meta/main.yml template that relied on it.
* Fix whitespace issue
'encrypt_string' only options were being referenced when using
other vault subcommands. That code is moved inside a check
for 'encrypt_string' action now.
This commit adds a connection driver built on top of systemd-nspawn.
This is similar to the existing `chroot` driver, except that nspawn
offers a variety of additional services. For example, it takes care of
automatically mounting `/proc` and `/sys` inside the chroot environment,
which will make a variety of tools work correctly that would otherwise
fail.
You can take advantage of other system-nspawn features to perform more
complicated tasks. For example, on my x86_64 system I have a Raspberry
Pi disk image mounted on `/rpi`. I can't use `chroot` with this because
the binaries contained in the image are for the wrong architecture.
However, I can use the systemd-nspawn `--bind` option to automatically
insert the appropriate qemu-arm binary into the container using an
inventory file like this:
pi ansible_host=/rpi ansible_nspawn_extra_args='--bind /usr/bin/qemu-arm --bind /lib64'
See http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html
for more information about systemd-nspawn itself.
* Add a vault 'encrypt_string' command.
The command will encrypt the string on the command
line and print out the yaml block that can be included
in a playbook.
To be prompted for a string to encrypt:
ansible-vault encrypt_string --prompt
To specify a string on the command line:
ansible-vault encrypt_string "some string to encrypt"
To read a string from stdin to encrypt:
echo "the plaintext to encrypt" | ansible-vault encrypt_string
If a --name or --stdin-name is provided, the output will include that name in yaml key value format:
$ ansible-vault encrypt_string "42" --name "the_answer"
the_answer: !vault-encrypted |
$ANSIBLE_VAULT;1.1;AES256
<vault cipher text here>
plaintext provided via prompt, cli, and/or stdin can be mixed:
$ ansible-vault encrypt_string "42" --name "the_answer" --prompt
Vault password:
Variable name (enter for no name): some_variable
String to encrypt: microfiber
# The encrypted version of variable ("some_variable", the string #1 from the interactive prompt).
some_variable: !vault-encrypted |
$ANSIBLE_VAULT;1.1;AES256
< vault cipher text here>
# The encrypted version of variable ("the_answer", the string #2 from the command line args).
the_answer: !vault-encrypted |
$ANSIBLE_VAULT;1.1;AES256
< vault cipher text here>
Encryption successful
* add stdin and prompting to vault 'encrypt_string'
* add a --name to encrypt_string to optional specify a var name
* prompt for a var name to use with --prompt
* add a --stdin-name for the var name for value read from stdin
Instead of populating the platform comment in the default
meta/main.yml with a dict of platforms fetch from the
galaxy REST API, this removes the API call and adds a
commented out example platforms list to the default meta/main.yml
Fixes#18103
* Improve ansible-galaxy handling of role versions
Ensure that role versions are considered when deciding
whether or not to (re-)install a role.
Issue a warning when the version of a dependency conflicts
with the version of an already installed role
Display what version of a role is being installed
Show the versions when upgrading/downgrading a role.
Implements #11266
* Improve force logic for galaxy version changes
Ensure that force is required to change role versions
if ANSIBLE_VAULT_PASSWORD_FILE is set, 'ansible-vault rekey myvault.yml'
will fail to prompt for the new vault password file, and will use
None.
Fix is to split out 'ask_vault_passwords' into 'ask_vault_passwords'
and 'ask_new_vault_passwords' to make the logic simpler. And then
make sure new_vault_pass is always set for 'rekey', and if not, then
call ask_new_vault_passwords() to set it.
ask_vault_passwords() would return values for vault_pass and new
vault_pass, and vault cli previously would not prompt for new_vault_pass
if there was a vault_pass set via a vault password file.
Fixes#18247
When using the ansible-galaxy CLI to import roles, it's not possible to
specify an alternate_role_name, even though the REST API seems to allow
such a thing (at least on investigation of the interactions the web app
makes) That makes importing things like:
openstack/openstack-ansible-os_cloudkitty wind up with roles named
"openstack-ansible-os_cloudkitty" instead of "os_cloudkitty".
Also, the web ui is smart and imports
"openstack-infra/ansible-role-puppet" as openstack-infra.puppet ... but
the CLI imports it as openstack-infra.ansible-role-puppet. Add that
filtering as well.
Issue ansible/galaxy-issues:#185
scottb