Ah OK. Yes, I understood "These variables will survive between plays" meant survive between invocations of ansible. If that's not the case and the fact is not cached to disk, then I can go with that approach.
Thanks On Monday, November 3, 2014 1:26:12 PM UTC, Matt Martz wrote: > > I think you are misunderstanding terminology slightly. > > Vars set with set_fact will be across plays but not invocations of ansible. > > A playbook can have multiple plays and multiple playbooks can be included > and executed in 1 invocation of ansible. > > set_fact is in memory only, and will not persist between invocations. > > On Monday, November 3, 2014, Mark <[email protected] <javascript:>> > wrote: > >> I was searching for exactly this feature. set_fact doesn't work for me >> because in my case i need to create AWS API keys for a newly created IAM >> user. The docs in set_fact says that the new fact will be available between >> plays, which means those keys will be cached on disk which represents a >> security risk. >> >> What I really would like is the same as the original poster - a way to >> get the stdout from the command module in a way that can be used later. >> E.g. after creating a new IAM user and registering the output as 'iam', and >> running: >> >> - name: Create access keys for the new user >> local_action: command aws iam create-access-key --user-name {{ >> iam.stack_outputs.UserName }} >> register: keys >> >> - name: debug keys >> debug: var=keys >> >> I see: >> >> ok: [localhost] => { >> "keys": { >> "changed": true, >> .... >> "stdout": "{\n \"AccessKey\": {\n \"UserName\": >> \"MyUser-UMF4KM2DRQWQ\", \n \"Status\": \"Active\", \n >> \"CreateDate\": \"2014-11-03T12:52:44.458Z\", \n >> \"SecretAccessKey\": \"***\", \n \"AccessKeyId\": \"AK***\"\n >> }\n}", >> >> I'd like to then pass the SecretAccessKey and AccessKeyId into another >> cloudformation template as parameters. The simplest way would be if this >> json could be parsed by the 'command' module and made available as a dict. >> >> Alternatively, is there any way of using 'set_fact' in a transient mode >> so the fact won't persist between invocations? >> >> On Tuesday, July 15, 2014 4:33:42 PM UTC+1, Michael DeHaan wrote: >>> >>> You cannot register the result of an expression. >>> >>> See what was posted about "set_fact" above, however. >>> >>> >>> >>> >>> On Mon, Jul 14, 2014 at 4:57 PM, Stuart Reynolds <[email protected]> >>> wrote: >>> >>>> On Monday, July 14, 2014 12:39:23 PM UTC-7, Michael DeHaan wrote: >>>>> >>>>> well it does return content already, all the stdout and such. >>>>> >>>> >>>> >>>> I see -- but I don't see how to usefully use that in subsequent tasks >>>> (beyond debug). >>>> I can do: >>>> register: result=std_out|to_json >>>> Or some such? >>>> >>>> >>>>> I think what you are saying is that have a flag that if the output of >>>>> the command is already JSON and you requested this behavior, return the >>>>> JSON datastructure in an element called "json"? >>>>> >>>> >>>> Yes. That's my specific problem. >>>> >>>> More generally, it raises the question: how can I operate on the >>>> results of an action (in code I write in playbooks and tasks vs modules)? >>>> The scope of what's possible isn't clear to me from the docs. Can I say, >>>> filter a list of results (e.g. from ec2_describe) and store the results in >>>> another list with an named value? >>>> >>>> >>>> I'm somewhat open to it, but also think that because it's possible to >>>>> do the "from_json" stuff with set fact, we have a bit of a solution, and >>>>> it >>>>> *might* be used in such a minority set of use cases skimming over the >>>>> option for most might cause greater confusion. >>>>> I don't know. >>>>> >>>>> To be clear, I'm suggesting this: >>>>> >>>>> - set_fact: >>>>> foo: "{{ x | from_json }}" >>>>> >>>> >>>> Doesn't this only assign a fact to the target host? >>>> In many cases, that's not the desired behavior. Suppose I want to >>>> collect a list of RDS instances ids by tag and perform simple operations >>>> on >>>> them over and over? >>>> >>>> Being able to: >>>> - add variables >>>> - trigger conditions >>>> - filter output, join lists... etc... >>>> >>>> would be tremendously useful. I guess something like: >>>> >>>> - hosts: localhost >>>> - name: Describe instances >>>> hosts: localhost >>>> gather_facts: false # Prevents immediately logging in to hosts >>>> tasks: >>>> - command: aws ec2 describe- >>>> instances >>>> after: > >>>> some python code to filter the results >>>> some python code to register 5 groups >>>> some python code to register 2 variables (register) >>>> isn't possible? >>>> >>>> This is just an example, I'm already using ec2.py for much of this. But >>>> more fined-grained controlled is required (such as having tasks >>>> conditionally execute or wait on ec2_instance states which may change in >>>> response to prior tasks). >>>> >>>> - Stu >>>> >>>> -- >>>> 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/6e552272-5da4-48b4-acf7- >>>> 8389265441a2%40googlegroups.com >>>> <https://groups.google.com/d/msgid/ansible-project/6e552272-5da4-48b4-acf7-8389265441a2%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/2a3f8912-185c-444f-91d7-cb696022feae%40googlegroups.com >> >> <https://groups.google.com/d/msgid/ansible-project/2a3f8912-185c-444f-91d7-cb696022feae%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > Matt Martz > @sivel > sivel.net > > -- 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/bd6cba6a-2336-456c-938e-7975fb5cb95f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
