Michael, Stephen, I appreciate you taking the time to respond to this old thread, and for your thoughts, and for all your hard work on Ansible.
I will work on a PR for this. Ned. On Thursday, July 31, 2014 5:53:02 PM UTC-6, Michael DeHaan wrote: > > I'm open to making set_fact work with with_items (pull request welcome). > > not having tested it recently - I'm actually surprised it didn't :) > > > > On Thu, Jul 31, 2014 at 7:02 PM, Stephen Gargan <steve....@gmail.com > <javascript:>> wrote: > >> Ned, >> >> There are better patterns for sharing data that what I'd originally >> suggested. As your system grows this approach gets untenable. If you need >> to share data variable files are a far more flexible solution. >> >> As Michael says, if you post another thread explaining of what you're >> trying to we'll gladly help you out. >> >> Thanks, >> >> Steve. >> >> >> On Thu, Jul 31, 2014 at 11:41 PM, Michael DeHaan <mic...@ansible.com >> <javascript:>> wrote: >> >>> So that's a very old thread you've replied to, can you paste an example >>> of what you are wishing to do? >>> >>> >>> >>> >>> On Wed, Jul 30, 2014 at 8:51 PM, Ned McClain <n...@appliedtrust.com >>> <javascript:>> wrote: >>> >>>> Stephen, >>>> >>>> I also desperately need a set_facts that works with with_items. Have >>>> you had any response to these excellent use-case examples? >>>> >>>> Ned. >>>> >>>> >>>> On Monday, November 11, 2013 11:14:41 AM UTC-7, Stephen Gargan wrote: >>>>> >>>>> Michael, >>>>> >>>>> I've put together an implementation for an add_facts command a couple >>>>> of examples that show what it might be useful for here >>>>> https://github.com/sgargan/ansible-add-facts-examples. I think it >>>>> explains the intention of the command a little better and gives a >>>>> concrete >>>>> example of the pattern I was attempting to explain above. I'm interested >>>>> to >>>>> hear what your thoughts are. >>>>> >>>>> thanks, >>>>> >>>>> Steve. >>>>> >>>>> On Wednesday, 6 November 2013 22:48:22 UTC-8, Stephen Gargan wrote: >>>>>> >>>>>> I've a pattern that I want to apply and I'm wondering what the best >>>>>> practice might be for this. I have a situation where I apply a number of >>>>>> roles to a host and each have a number of facts or variables that I'd >>>>>> like >>>>>> to use in a final role, typically to generate a unified config for the >>>>>> host. >>>>>> >>>>>> Say I'm applying a number of roles say a, b, c that are all distinct, >>>>>> but each exposes a set of metrics in a uniform way. As each gets played, >>>>>> I'd like to add facts about the metrics for the role in such a way that >>>>>> I >>>>>> can iterate over them in a final role d to generate some aggregate >>>>>> config >>>>>> to expose all the metrics. >>>>>> >>>>>> I have a number of situations that I'd like to apply this pattern so >>>>>> if there is a standard way to do this I'd love to hear it. >>>>>> >>>>>> If not, I have been mulling over extending the set_fact module to >>>>>> allow something like the following >>>>>> Say each role could add a dictionary of values to an aggregate >>>>>> collection, aggregated_facts, so that in d I could do >>>>>> >>>>>> {% for addedFactsForRole in aggregated_facts %} >>>>>> // processing facts for key addedFactsForRole.key >>>>>> {% for addedFact in addedFactsForRole.facts %} >>>>>> // process addedFact.name >>>>>> // process addedFact.value >>>>>> {% endfor %} >>>>>> {% endfor %} >>>>>> >>>>>> I have used group variables to do something similar, but this tends >>>>>> to get crufty as it means replicating the data in every site that I use >>>>>> the >>>>>> role and I like to be able to have very generic roles that I can reuse >>>>>> in >>>>>> different sites. If the list could dynamically built like this it would >>>>>> be >>>>>> arguably more cohesive as now I could define all of the data for the >>>>>> role, >>>>>> within the role, and still have the ability to override it at the site >>>>>> level with group vars. >>>>>> >>>>>> I'm thinking the task definition might look something like this. >>>>>> >>>>>> name: Add metrics to metrics aggregate >>>>>> add_fact: group=host_metrics key=$role_key fact=$item >>>>>> with_items: $list_of_metrics >>>>>> >>>>>> In the case above the list_of_metrics could be a list of single >>>>>> entries or a list of json blobs. I don't want to go re-inventing the >>>>>> wheel, >>>>>> this seems like a common enough scenario so I'm very curious how folks >>>>>> tackle it, before I go about putting this together. >>>>>> >>>>>> Thanks in advance, >>>>>> >>>>>> Steve. >>>>>> >>>>> -- >>>> 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 <javascript:>. >>>> To post to this group, send email to ansible...@googlegroups.com >>>> <javascript:>. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/ansible-project/d6bd87d4-d208-4890-9ff1-e17d81778e6f%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/ansible-project/d6bd87d4-d208-4890-9ff1-e17d81778e6f%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >>> 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/ObxLwj_egEI/unsubscribe >>> . >>> To unsubscribe from this group and all its topics, send an email to >>> ansible-proje...@googlegroups.com <javascript:>. >>> >>> To post to this group, send email to ansible...@googlegroups.com >>> <javascript:>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxadOn-kkLwu6Fsr3SbER6bPAHeaeQgvqUsy9QygA3M2A%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxadOn-kkLwu6Fsr3SbER6bPAHeaeQgvqUsy9QygA3M2A%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> 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 <javascript:>. >> To post to this group, send email to ansible...@googlegroups.com >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/ansible-project/CAPe9%3DrDZnoOL-UeD7ejcBY22uw%2BqJRpZkGzxAWJCsZUe_KygrQ%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/ansible-project/CAPe9%3DrDZnoOL-UeD7ejcBY22uw%2BqJRpZkGzxAWJCsZUe_KygrQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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-project+unsubscr...@googlegroups.com. To post to this group, send email to ansible-project@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/a764ab4a-7884-4a7b-845b-95218aa85481%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
