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 <[email protected] > <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 <[email protected] >> <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 <[email protected] >>> <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 [email protected] <javascript:>. >>>> To post to this group, send email to [email protected] >>>> <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 >>> [email protected] <javascript:>. >>> >>> To post to this group, send email to [email protected] >>> <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 [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <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 [email protected]. To post to this group, send email to [email protected]. 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.
