failed: [127.0.0.1] => {"failed": true, "parsed": false}
invalid output was: Traceback (most recent call last):
File "/tmp/ansible-1376083321.99-111209413777779/nova_compute", line 1176, in <module>
main()
File "/tmp/ansible-1376083321.99-111209413777779/nova_compute", line 239, in main
_get_server_state(module, nova)
File "/tmp/ansible-1376083321.99-111209413777779/nova_compute", line 198, in _get_server_state
private = [ x['addr'] for x in getattr(server, 'addresses').itervalues().next() if x['OS-EXT-IPS:type'] == 'fixed']
KeyError: 'OS-EXT-IPS:type'
This extension was added less than 6 month ago, and so cannot be used on a release
older than Grizzly ( like Folsom ).
Commit of the extension : https://review.openstack.org/#/c/21453/
See https://wiki.openstack.org/wiki/ReleaseNotes/Grizzly#Key_New_Features_2
When service module is used on unsupported Linux system where init
script is used directly, LinuxService.svc_cmd is None so .endswith()
fails.
Fixes issue #3533
Both modules dealing with rax resources should use the same arguments
and environmental variables. The author of rax_clb_nodes did some things
better so sync rax with that effort.
I'm seeing ansible hang when trying to remove a package, and the hung
process is `whiptail` like in #2763. It looks like we only use
`APT_ENVVARS` and `DPKG_OPTIONS` for the `apt` commands in install()
and upgrade(). This change uses them in remove() as well, which fixes
the hang.
Remove the reference to the unused "termination_list" parameter
in the ec2 module. The instance_ids parameter is the one that contains
the list of instance ids to be terminated.
Boto blindly assumes the us-east-1 region if you don't hardcode a
region in it's config, so you could end up attempting to modify ELB's
in one region from a totally different region. If a region isn't
specified then default to the region that the module is being run
within rather than the default us-east-1 region since it's a pretty
safe assumption that you intend to work on the ELB's within your
current region.
Also throw an error if a specified ELB instance doesn't exist. The old
behavior would be to silently succeed with changed=false, so if you had
so much as a typo in the name of your ELB (or were in the wrong region
like my initial testing) you wouldn't get a clear indication that a
problem had occurred.
"UnboundLocalError: local variable 'branch' referenced before assignment" is
raised in git, line 282, in switch_version.
Exception is raised when version is not branch and version checkout fails.
E.g. when version is nonexistant commit.
This enables sending messages to partychat-like services (e.g. im.partych.at).
This commit also fixes handling of 'to' argument for non-chatroom recipients.
The timeout parameter of glance-image was not being parsed into a
numeric type, causing the following error when specifying timeout:
msg: Error in creating image: unsupported operand type(s) for +: 'float' and 'str'
The apt-key command takes an optional --keyring parameter representing
the path to a specific GPG keyring to operate on. If it's not given,
the command operates on all keyring files, i.e., /etc/apt/trusted.gpg
and /etc/apt/trusted.gpg.d/*.gpg.
This change adds a 'keyring' parameter to the apt_key module and
propagates it down to the apt-key command line. The main use case this
supports is organizing keys for third-party repos into individual
keyrings in /etc/apt/trusted.gpg.d, rather than putting them all in
the default keyring.
When revoking privileges from a user, the GRANT OPTION is always
revoked, even if the user doesn't have it. If the user exists, this
doesn't give an error, but if the user doesn't exist, it does:
mysql> GRANT ALL ON test.* TO 'test'@'localhost';
Query OK, 0 rows affected (0.00 sec)
mysql> REVOKE GRANT OPTION ON test.* FROM 'test'@'localhost';
Query OK, 0 rows affected (0.00 sec)
mysql> REVOKE GRANT OPTION ON test.* FROM 'test'@'localhost';
Query OK, 0 rows affected (0.00 sec)
mysql> REVOKE ALL ON test.* FROM 'test'@'localhost';
Query OK, 0 rows affected (0.00 sec)
mysql> REVOKE GRANT OPTION ON test.* FROM 'test'@'localhost';
ERROR 1141 (42000): There is no such grant defined for user 'test' on
host 'localhost'
Additionally, in MySQL 5.6 this breaks replication because of
http://bugs.mysql.com/bug.php?id=68892.
Rather than revoking the GRANT OPTION and catching the error, check if
the user actually has it and only revoke it when he does.