Previously, the `promote` command in the `rds` module would always return OK and never actually promote an instance. This was because `promote_db_instance()` had its conditions backwards: if the instance had the `replication_source` attribute indicating that it **was** a replica, it would set `changed = False` and do nothing. If the instance **wasn't** a replica, it would attempt to run `boto.rds.promote_read_replica()`, which would always fail.
'exact_count' and 'state' are mutually exclusive options they should not be in the following examples:
- # Enforce that 5 running instances named "database" with a "dbtype" of "postgres" example and
- # Enforce that 5 instances with a tag "foo" are running
The yum module allows the 'name' parameter to be given as 'pkg', in
a similar way to some of the other package managers. This change
documents this alias.
The module's 'state' parameter has two other aliases, in line with
the 'apt' action; the 'state' parameter can take 'installed' as an
alias for 'present', and 'removed' as an alias for 'absent'. These
aliases are documented.
The command `hg up -C` by default moves to the latest revision on the
current branch. The `discard` function was trying to update to a
different branch, in case it was provided, by passing a `-r REVISION`
argument. Not only is this not the intended effect of the `discard`
function, but this also could update to a different branch that hasn't
been pulled yet, which is how we were experiencing trouble.
Instead, we unconditionally do `hg up -C -r .` to "update" to the
current revision (i.e. to "."), while `-C/--clean`ing the current
directory. This is similar to `hg revert --all`, except that it also
undoes the merge state of the working directory, in case there was
any.
The min_disk and min_ram parameters were not being passed to
the shade API. They also need to be integer values. Also
updated the description of these parameters for better
clarification.
Previously the logging module hard coded the default logging driver. This means
if the docker daemon is started with a different logging driver, the ansible
module would continually restart it when run.
This fix adds a call to docker.Client.info(), which is inspected if a logging
driver is not supplied in the playbook, and the container only restarted if
the logging driver applied differs from the configured default.
In usage, this has solved issues with using alternative logging drivers.
