Definitely - I desire to have different roles append firewall rules (strings) to a single fact dictionary. The final role will apply those generic rules to the appropriate iptables/ufw/ec2 security group based on the host's OS and cloud provider. Allowing each role to append their own rules to the fact is a highly compostable solution. It abstracts role-provided firewall rules from the host OS and hosting environments those roles are applied to.
I stumbled across Steven's super-detailed example that described the use case(s) very clearly: https://github.com/sgargan/ansible-add-facts-examples To me, the current outcome of using "set_fact" along with "with_items" very much defies the "Principle of least surprise". I was sure surprised. Note this request is in NO WAY for new "programming language" functionality in Ansible - this is simply a request to make "set_fact" work in the least surprising way when used with "with_items". Thanks for considering this, Ned. On Thursday, July 31, 2014 4:41:43 PM UTC-6, Michael DeHaan 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 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/7af913d1-0004-4923-a5bf-49ac51cae16d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
