-
Notifications
You must be signed in to change notification settings - Fork 1.5k
In rabbitmq_policy, tags values that should be ints are passed in a strings #1308
Comments
[module: messaging/rabbitmq_policy.py] |
@retr0h, ping. This issue is still waiting on your response. |
Hi. This is fixed. have a look at the below ansible setup :
What you need is the latest rabbitmq-server that support rabbitmqctl set_policy for the "max-length-bytes" . If you can set this from the command line , than my above sample will work for you. |
@retr0h, ping. This issue is still waiting on your response. |
@retr0h, ping. This issue is still waiting on your response. |
no longer an issue. |
@retr0h, ping. This issue is still waiting on your response. |
1 similar comment
@retr0h, ping. This issue is still waiting on your response. |
@retr0h, ping. This issue is still waiting on your response. |
This repository has been locked. All new issues and pullrequests should be filed in https://github.com/ansible/ansible Please read through the repomerge page in the dev guide. The guide contains links to tools which automatically move your issue or pullrequest to the ansible/ansible repo. |
This issue was migrated to ansible/ansible#29244 |
ISSUE TYPE
Bug Report
COMPONENT NAME
rabbitmq_policy module
ANSIBLE VERSION
N/A
SUMMARY
I worked around the bug described below (the original report was from a colleague) with the following hack:
I can set the max-length-bytes for a rabbitmq_policy as follows:
where max-length-bytes is set to a literal number. This works fine. But I need to replace the literal with a variable like this:
where of course the value of rabbit_queue_normal_priority_max_bytes comes from an inventory, where it is an unquoted number literal. When I run the playbook I get this error:
So I put quotes around it:
and then I get this error:
I.e., it interpreted the value as a quoted string. Googling around, I find that you are supposed to cast the variable to its type; e.g.:
but this resulted in exactly the same error as above. There are some posts saying that this was a problem in an earlier Ansible release, but see also ansible/ansible#5463
The text was updated successfully, but these errors were encountered: