provider
Provides a dynamic inventory plugin for Scaleway cloud provider with
the following features:
- Configurable scaleway.ini file
- Cache API responses
- Choose public or private IPs
- Create groups per Scaleway 'tags'
- Create groups per Scaleway regions
Fix typo. The use of `dest` for group_by_aws_account causes the group to be produced using IP and to duplicate the hosts in the inventory.
Fixes#23772
Signed-off-by: bo <robert@jbanetwork.com>
This fix adds replacement for exit() to sys.exit(), as
exit() is not recommended way to exit from the program.
Signed-off-by: Abhijeet Kasurde <akasurde@redhat.com>
Fix adds default 'vmware' section in configuration,
when this section is not found.
Fixes: #31549
Signed-off-by: Abhijeet Kasurde <akasurde@redhat.com>
This fix changes default value of host_filter in vmware_inventory.py
and vmware_inventory.ini to 'runtime.powerstate' from 'guest.gueststate'.
This change is added as 'guest.gueststate' requires vmware tools to be
installed on given VM, which may not be the case everytime.
Fixes: #25086
Signed-off-by: Abhijeet Kasurde <akasurde@redhat.com>
This patch add new environment variables to oVirt dynamic inventory
to be consistent with all other oVirt modules:
OVIRT_URL
OVIRT_USERNAME
OVIRT_CAFILE
OVIRT_PASSWORD
Those variables are used as fallback if user don't specify a ini file,
with appropriate variables there.
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.
* Set missing default values for EC2 inventory
* Make it run even with no ec2.ini file
* Fixing INI file reading
* Refactor how defaults are handeled
Define defaults in a dictionary and use .get rather than if statements with has_option
* Removing double keys and fixing logic for instance_filter
* Removing one more doubled key
* Allow filtering RDS instances by tags in the ec2.py dynamic inventory script
* PEP8 fix
* Fix no-bastring code smell
* Simplify logic in ec2.py RDS filtering by tag
* Update docker inventory to use APIClient
docker-py has been updated, and the `Client` class no longer
exists. We use the new `APIClient` class.
To provide graceful failure when docker-py is not installed,
we need to create a dummy `Client` class so that the inventory
script will get as far as displaying a useful error message
Before
```
$ contrib/inventory/docker.py --pretty
Traceback (most recent call last):
File "contrib/inventory/docker.py", line 418, in <module>
class AnsibleDockerClient(Client):
NameError: name 'Client' is not defined
```
After
```
$ contrib/inventory/docker.py --pretty
Failed to import docker-py. Try `pip install docker-py` - cannot import name Client
```
* docker inventory configuration file location
Allow docker.yml to live next to docker.py, as well as in the
current directory
Ansible documentation states that env variable based authentication bases on variable GCE_CREDENTIALS_FILE_PATH while gce.py reads only GCE_PEM_FILE_PATH (see https://docs.ansible.com/ansible/guide_gce.html). This commit adds GCE_CREDENTIALS_FILE_PATH to the configuration chain; if set it will be used.
* Can be set via env, credential profile, or module arg
* Valid values defined by Azure Python SDK, currently `AzureCloud`,`AzureChinaCloud`,`AzureUSGovernment`,`AzureGermanCloud` or any Azure Stack metadata discovery URL.
* Fixup the property collection for dictionaries vs. objects
* Remove debug lines
* Do not attempt to sort because it's a waste
* Remove unused code
* Remove extra code
* Capture lowercase keys
* Fix 'the the' typos, fix 'pahting' filename typo
* Change 'the the' typos to a single 'the'.
* Change `playbook_pahting.rst` to `playbook_pathing.rst`.
* Delete trailing space in ec2_vol example
Delete the trailing space in `instance: "{{ item.id }} "`, which makes the
example fail when run because it looks for instance "i-xxxx ".
* Compatibility of gce.py (inventory) with Python 3
* Revert './secrets.py' file check (will import 'secrets' from PYTHONPATH)
Instead of checking if secrets.py exists in the current directory, this
commit will make gce import 'secrets' from one of PYTHONPATH's paths.
There are 2 possibilities:
1. secrets.py will be used if secrets.GCE_PARAMS and
secrets.GCE_KEYWORD_PARAMS are declared.
2. secrets.py will be ignored if secrets.GCE_PARAMS and
secrets.GCE_KEYWORD_PARAMS aren't declared. This could happen in Python
>=3.6 where a module named 'secrets' could be imported if a custom
secrets.py doesn't exist in PYTHONPATH.
Check out https://www.python.org/dev/peps/pep-0506/ and
https://docs.python.org/3/library/secrets.html for more information.
