New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Complex argument parsing returns arrays or objects as strings in ansible 2.1.0 #16057
Comments
Ah, it seems that it is now necessary to specify a type in
Would love to see some docs on this, as it's a change in behavior. |
I also ran into this with a custom module. The undocumented workaround specified by @yourcelf does not help if you actually want a complex arg that might be any of several types. As a module author, if you were relying on the yaml parser to produce nested dictionaries, you now have to figure out a safe way to eval the stringified representation of what once was a python object. |
@nordjc When you do this, can you provide an example solution to this issue so that other module developers could use it? Thanks! |
@nordjc Couple things to note (Already talked to @drybjed on IRC). I'll start with the one that should help you first:
The first example is in yaml dict format. When ansible parses the playbook, the yaml library will parse each dictionary entry and hand them back to Ansible in a structured format. The mode will be an integer number 420 in base 10. So the module will be handed the base 10 integer 420. base 10 420 is octal 0644, a common file permission. The second example is in key=value format. In this case, yaml will hand Ansible a single string as the value of copy. Ansible will then parse the string into key=value pairs. In this case, all of the values are strings after this parsing. Ansible passes these strings across the wire to the modules. So the copy module receives mode="420". The module then assumes the mode is octal 0420 and sets it accordingly. So if a module really wants to be non-buggy and uses type=raw it has to be able to handle both cases: when it is given the parameter via yaml dicts it will be in a real type. When given via key=value it will be a string htat has to be parsed further. |
I have the same issue with the ec2_elb_lb module that have an expected numeric parameter in the stickiness object but is valued as string by ansible thus not functioning correctly. |
(Mentioning #17992 here to keep track of related issues) There is a light at the end of the tunnel. We made a change to Jinja2 so we don't see all variable types changed into strings. See: pallets/jinja#708 |
This is expected behavior as we did purposefully change the default of a missing type to default to As this issue report is as old as it is, I don't think a porting guide entry is necessary at this time. If you have further questions please stop by IRC or the mailing list:
|
ISSUE TYPE
COMPONENT NAME
core
ANSIBLE VERSION
(I've altered the paths referenced here; but both are custom).
CONFIGURATION
My ansible.cfg specifies a custom library path and a custom roles path.
OS / ENVIRONMENT
Ubuntu 14.04.4
SUMMARY
In Ansible 2.1.0, it seems that complex arguments are not getting properly parsed into array or object types, and are presented to the module as strings instead.
STEPS TO REPRODUCE
Here is a minimal module that demonstrates the problem. All the module does is check that the argument
mylist
is a list type, and fails of it is not, indicating the type in the failure message:with this playbook:
Running this playbook fails with the following error:
EXPECTED RESULTS
I expected that retrieving an argument within a module with
module.params['varname']
returns the parsed structured type, be that a list, dictionary, or what have you. This is how it worked in ansible v2.0.ACTUAL RESULTS
Retrieving an argument via
module.params['varname']
is returning a string, even whenvarname
is a structured object or list in the yaml file.Are we now expected to do further parsing/eval'ing of argument contents in order to get structured output, or is there some other way to retrieve the structured params?
The text was updated successfully, but these errors were encountered: