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]>
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]>
> 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]>
>> 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].
>>>  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/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].
>>
>> 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/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].
> 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/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/CA%2BnsWgytAoBvnM6hAH2Q2svtTmmunGFJJS8o0UpOR8spxB9XvQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to