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 <[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 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/7af913d1-0004-4923-a5bf-49ac51cae16d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
