The following works with 0.9 and earlier, but fails with 1.1 and trunk:
test11.yml:
hosts: somehosts
user: ansible
sudo: yes
vars:
component: { ‘name’ : ‘tomcat6’ , ‘version’ : ‘6.0.24-48.el6_3’ }
tasks:
task11.yml:
Looks like you are sending a list of lists when you should be sending a single list.
I believe we fixed a glitch where it would auto-flatten before, because it may be useful to preserve exactly what you requested.
In either way, it’s not really documented that lists of lists should magically flatten, so I think it working as advertised is acceptable.
You can fix this problem by changing [[ $foo ]] to [ $foo ]
No.
I condensed this to illustrate the problem, I know I can pass in a list, that’s obvious, but that doesn’t represent our application structure.
Nowhere is it documented that a list of lists won’t flatten in this manner. Versions 0.8 through 1.0 flattened just fine in this manner while we were building the guts of our infrastructure.
This is a critical blocker for us; our base structure is 2-level. We don’t have a workaround.
Nor was it ever documented that they did flatten in this matter.
It seems like you were relying on a bug to me, for quite the opposite I say should be true, that you could pass lists of lists to with_items and expect the structure to be preserved. I know lots of content that would do that and index $item.0 and item.1, and it would be wrong to break those people because you were using an undocumented feature. Sorry.
You can definitely write your own “with_flattened” should you not wish to change whatever you are doing, using the 0.9 with_items as a guide.
I spent a couple of days and reworked this by transforming the problematic representation via jinja2 and python-land.
(This is an example of my observations in other posts on needing to go outside Ansible whenever one needs to do progressive logic)
The with_flattened path may make sense technically, but I chose not to go down that route because that will open us up to just a different mode of future incompatibility - well unless it can be done on top of an existing, maintained API.
Now that I’m through the worst of this, I will respond to some of your other comments in more detail later.
The filter plugins are a maintained API.
Please don’t imply they are not.
Correction, “lookup plugins”.
Then this is a valid path, good to know. No implication was intended, didn’t mean for it to come across that way.