Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Faulty parsing of JSON template/file lookups (aka JSON double-quotes to single-quotes conversion problem) #15603
Default from Git master
OS / ENVIRONMENT
Debian Jessie x86_64
The problem is that Jinja2 templating is done recursively and I could not find any combination of
- Bug fix PR that was fixing the symptom in `iam_policy` module with `policy_json` arg: https://github.com/ansible/ansible-modules-core/pull/3019 - Another new (unreported yet) bug caused by this logic breaks `policy` argument in `s3_bucket` module here if you use a lookup: https://github.com/ansible/ansible-modules-extras/blob/devel/cloud/amazon/s3_bucket.py#L211
I'd probably fix this myself but I just don't have the time to do it :(
STEPS TO REPRODUCE
JSON posted to AWS is valid and bucket is created
Also has issues in s3_module where the resulting arg is a string (not a dict) with singlequotes:
There was also a similar bug with the uri module (which takes a json parameter) earlier. Looking at the fix for that bug I see that we added code to the module so that if it received a string it would pass it through but if it received a python dict or list it would turn that into a json string. That would probably work here or for any other json string as well. There are some conceptual problems to it which could be confusing -- for instance, the use of to_json in your original playbook is probably doing the wrong thing, running a json string through to_json (which means things are double escaped) but it would at least make a workaround for things. We could ease the burden for module writers by giving them a new arg_spec type to use. If type is jsonstring, then we could do the json.dumps(param) if the type is not a string already.
I'd like to get more input from other core team members as to whether this is the right way to go before merging a fix like that.
@bcoca Seems like a good fix for
@sgnn7 the issue is how module authors define the expected input, not much we can do on the Ansible side but blindly guess.
We do have those flags (and filters), they would still not help with 1/2 of those modules as they are not dealing with the input consistently.