Taking a page out of the ec2 config, make sure that all of the
OpenStack modules handle the inbound auth config in the same way.
The one outlier is keystone wrt auth_url.
The OpenStack client utilities consume a set of input environment
variables for things like username and auth_url, so it's very
common for OpenStack users to have such settings set in their
environment. Indeed, things like devstack also output a shell file
to be sourced to set them. Although in a playbook it's entirely
expected that variables should be used to pass in system settings
like api passwords, for ad-hoc command line usage, needing to pass
in five parameters which are almost certainly in the environment
already reduces the utility.
Grab the environment variables and inject them as default. Special care
is taken to ensure that in the case where the values are not found, the
behavior of which parameters are required is not altered.
It is possible to create an instance, terminate the instance and then
attempt to recreate the instance with the same parameters. In this case
`ec2.run_instances` returns a reservation list containing the instance ids
but the logic gets stuck waiting for the instance to exist in the call to
`ec2.get_all_instances`, even if wait is no).
The provisioning module knows more about how nova deals with IP
addresses now. Ensure that the inventory module is similarly as smart
by separating out the logic into the openstack/module_utils.
During the state check, check IP address information. This gets us
two things. The most obvious is that for direct IP management, a
change to the config will reflect in the config of the instance. But
also, if we succeed in creating the instance but fail in adding an IP,
this should let us re-run and arrive in the state we were expecting.
The fun part about having multiple vendors providing the same cloud
is that while their APIs are the same, what they do with their metadata
tends to be ... fun. So in order to be able to express sanely what you
want without needing to stick tons of unreadable uuids in your config,
it turns out what sometimes you need to further filter image and flavor
names. Specific examples are (deprecated) images in HP Cloud and the
Standard and Performance flavors on Rackspace.
Putting uuid and numberic identifies in playbooks is fragile, especially
with cloud providers who change them out from under you. Asking for
Ubuntu 14.04 is consistent, the UUID associated with that is not. Add
mutually exclusive parameters to allow for specifying images by name and
flavors by RAM amount.
Taking a page out of the ec2 config, make sure that all of the
OpenStack modules handle the inbound auth config in the same way.
The one outlier is keystone wrt auth_url.
The OpenStack client utilities consume a set of input environment
variables for things like username and auth_url, so it's very
common for OpenStack users to have such settings set in their
environment. Indeed, things like devstack also output a shell file
to be sourced to set them. Although in a playbook it's entirely
expected that variables should be used to pass in system settings
like api passwords, for ad-hoc command line usage, needing to pass
in five parameters which are almost certainly in the environment
already reduces the utility.
Grab the environment variables and inject them as default. Special care
is taken to ensure that in the case where the values are not found, the
behavior of which parameters are required is not altered.
The floating-ip extension, while pretty ubiquitous, is not a
foregone conclusion. Specifically, Rackspace, while also
served by the rax module, is a valid OpenStack cloud and can
be interacted with directly via nova interfaces.
Add support for determining public and private IPs for
OpenStack clouds that don't use floating ips by reading
the public and private keys from the addresses dict.
If the region name is specified in the config, we need to pass it
in to the nova client constructor. Since key_name is similarly optional,
go ahead and handle both parameters the same.
The desires around getting a floating ip associated with a pool and
getting a floating ip not associated with a pool is just different
enough that following it as one set of nested ifs is tricky. Split
the function into two, one for the pool and one for the non-pool logic.
Several azure fixes/improvements, including:
* Improve failure message when python-azure is not installed
* Improve required argument handling
* Fixes a traceback on instance termination when the variable
'deployment' was not set.
* Fixes a traceback (#8298) when creating instances using the newer SDK
otherwise the module will return the info about the instance that it got prior to the action taken
So if you had a task to start an instance:
ec2:
instance_ids: ...
state: running
register: ec2_info
the registered data would have empty public_dns_name, public_ip, private_dns_name, private_ip
Michael DeHaan