set_fact support for list of dictionaries?

[E.C. Raymond]

What is the status on complex data storage for set_fact?  It seems like its not quite possible yet when I have tried multiple methods.

- name: testing

  set_fact: vms="['{ {{ item.item }}: {{ item.stdout.strip('\n') }} }']"

  with_items:

    - "{{ hostips }}"

I found these links that got me close enough, but I am guessing that this is not yet supported.

https://groups.google.com/forum/#!topic/ansible-project/cPbCD6R9TnE

http://stackoverflow.com/questions/23507589/is-it-possible-to-set-a-fact-of-an-array-in-ansible

Thanks.

[Michael DeHaan]

You are passing it a string above.

Don't do that.

Try this:

- set_fact:

      x: <valid YAML datastructure goes here>

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/4a9f3744-44b1-44b4-82e5-d3cc65fd5ed0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Serge van Ginderachter]

I have an outstanding PR for that:

https://github.com/ansible/ansible/pull/8019

--

[Michael DeHaan]

Oh nice.

This isn't related to your commit - I'm starting to worry a bit about continual buildup of inline code cruft in Runner - so we may hold off on this a little bit until we can refactor things a bit to find a good place for things like this.   This is a hard thing to stress on submissions, but over time, things build up.

In general, making some smaller functions and having the runner code call them would be a good idea.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAEhzMJCKqnE-Hc71oc_nHs2%3D5byeehLhzs7LePNB16REZymK7g%40mail.gmail.com.

[Serge van Ginderachter]

On 18 July 2014 13:42, Michael DeHaan <mic...@ansible.com> wrote:

I'm starting to worry a bit about continual buildup of inline code cruft in Runner - so we may hold off on this a little bit until we can refactor things a bit to find a good place for things like this.  

​Agreed. Maybe the way on how to refactor this can be discussed on -devel?
​

[Michael DeHaan]

Yeah it's more of a devel topic, but since we've started the thread, I'll share a bit.

I already have several things in mind - but they are hard to detail over text for me for an extent.  While I generally want to make this project as maximally open to code review as possible, with some exception, reviewing outside refactorings is one of those things that I want to audit like a razor and I need to be really really really careful, so in general, unless discussed first, we /don't/ take outside refactoring requests because they are too dangerous.   Some contributions are really easy - especially new things - to take in - and we have increasing test and integration coverage - though subtlety still lurks in places.   So just saying that so someone doesn't try - refactoring changes in certain places can also invalidate a lot of pull requests, though Runner is not one of those things that are in major flux.

It's really something James and I have some plans for, and it's going to start being a major priority over the coming releases or two.   It's also a bit more of a philosophy - when some code is touched, clean it up a bit and leave it more organized than it was originally.

I've also taken a few (aborted) stabs in this direction, so I have a feeling of where it needs to go.   It will probably start with just breaking more things into smaller functions, for starters, but eventually I want to see task objects passed into Runner directly.

For new folk, I do want to stress though that the tree is in good shape - we just want to make it even easier to contribute to, and easier to stretch in new directions, without making it harder to follow.

--

You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAEhzMJAmCrygKzOx03itw3x9VKAKMpbTR6GUZzShuBsYmnoXPA%40mail.gmail.com.

[Brian Jones]

Is this related to this odd set_fact behavior I'm encountering with ansible 1.7.1?

http://pastebin.com/iBwfp7gA

I don't want to use foo.stdout_lines because I intend to sometimes pass in foo via -e, hence why I'm trying to define a fact.

Brian

[Michael DeHaan]

You're replying to an old thread from July which was a little long, so I'm not sure what this inquiry was about.

"Is this related to this odd set_fact behavior I'm encountering with ansible 1.7.1?"

Could use some help clarifying what the pronoun "this" refers to.   Sorry, internets make this hard sometime :)

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/e4cdd1eb-2f17-4463-b886-38de9e2125f4%40googlegroups.com.

[Brian Jones]

I found a probably even older thread with a solution to my particular issue, demonstrated by the pastebin from my original message.

This doesn't work...

- set_fact: directories="{{ directories_output.stdout_lines }}"

This does work...

- set_fact:

  directories: "{{ directories_output.stdout_lines }}"

That's pretty screwy.

By work I mean, usable as an array in a Jinja2 template in a typical for loop.

Brian

--
You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/5IZZImuYafs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-proje...@googlegroups.com.

To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgymh88OBsWJPmEZbC-qzu8AjrfQ0JGbP_hbV_dd0T8bhg%40mail.gmail.com.

[Michael DeHaan]

It's not the least bit screwy.

If you are doing key=value stuff all on one line, Ansible doesn't know what is a string or not.

Jinja2 templating happens before values are past.

You are correct in that the long form set_fact does hold types nicely, and is what you want.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAACpEXKLezxR_NG8wjJG9E_Xd-Cq%3D404WP5Mn1QTs_XrKYzYvg%40mail.gmail.com.

[Michael DeHaan]

Also you actually mean this (note spacing):

- set_fact:

     directories: "{{ directories_output.stdout_lines }}"

This is because directories is not a parameter to the task, it's passed to the "set_fact" module.