Envirionment variable support in GCE inventory plugin.
Update version.
Merge pull request #8397 from lukesneeringer/gce-envvars

Add support for environment variables in GCE module.
Merge pull request #8398 from wrosario/integration_mysql_variables

Adding test Coverage for mysql_variable module
Merge pull request #8400 from nicocesar/devel

"allow_no_value=True" for ini_file module
Merge pull request #8405 from wenottingham/patch-2

Update version.
Fixes issue #8339 where Scientific Linux incorrectly tries to use FedoraStrategy of hostnamectl
Added floating IP functionality to nova_compute
Split nova floating-ip pool logic

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.
Pass through nova region name

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.
Add support for nova availability zones

If a cloud has availability zone support, it's possible to specify
an availability zone via the nova client. Add that as a config param.
Find IPs on OpenStack clouds without floating-ips

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.
Cleanup in nova after a failed floating ip

There is a potential leak of resources if there is somehow a failure
adding a floating ip to a server. Clean up after ourselves.
Consume standard OpenStack environment settings

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.
Add common auth handling across openstack modules

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.
Use mutually exclusive on nova floating ip params

ansible knows how to deal with mutually exclusive parameters, so
instead of coding that ourselves, use it.
Specify nova image and flavor by name

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.
Add ability to filter on image and flavor names

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.
Cleaned up nova_compute documentation

Added version_added tags as well as a few more examples.
Update existing nova instances with current ip

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.