The existing code was using:
a[b][c[d]]
where a[b] would always exist and c[d] would always exist.
But the nested index would not alway exist, particularly when a DigitalOcean item disapeared.
This changes that nested index to a `get` and properly handles None results.
This bug was present in two spots in this file.
The `dopy` library function all_images includes a 'global' filter
by default. This was preventing private images from showing up
in --images.
The problem also made this script fail immediately for people
who had droplets previously created with private images.
* Always refresh droplet information (versus getting it from cache) for
--list, --host, --droplets, and --all. All the DigitalOcean calls are
pretty fast and without this change, inventory was often stale/incorrect.
For example, previously if you destroyed a droplet, the inventory
script would still find it and attempt to act on it.
* Added --force-cache option
* Added some option shortcuts -d, -r
* Added more value sanitization
The rax inventory plugin provides a way to discovery inventory in the
Rackspace Public Cloud by way of pyrax, the official SDK. Grouping will
be done if a group:name is found in the instance metadata. When a single
host is queried all the instance details are returned with a rax_
prefix.
Because inventory plugins cannot take extra arguments, ENV variables
must be set to point to the pyrax compatible credentials file and the
region to query against.
Since callbacks are called with different argument-types, we have to be careful. We support two different distinct cases:
- The error information can be in one ore more of the following items (msg, stderr or stdout)
- The res/msg value returned can be a string or a list
This is useful mostly for playbooks that run unattended and for a limited set of systems. In case of provisioninging this plugin (together with a final mail action) helps to get notified when something went wrong, or when the installation finished successfully.
Unfortunately, there is no way to enable/disable a plugin from a playbook. So installing the plugin means all other use-cases (provisioning, troubleshooting, reporting or management) all send mails on failure. Something we may want to fix in the future...