Clarifying what I meant by modules.

When I'm writing the tasks in my playbooks, I tend to do a step-by-step
list of tasks instead of trying to bundle multiple steps into a single
task. So your original example (2 tasks) is generally how I would think of
writing it. The module (in our examples here the "file" part) performs a
single operation for each task. If I want it to do more operations, then I
just call it in more tasks.

Some of this batching of work begins to become more structured in ansible
2.0's blocks feature, but the example you showed in your initial post is
how I would have written it pending no further requirements.

I also tend to go the individual task route to prevent myself from trying
to be too smart for my own good. The example I provided that batches the
work would cause a mutiny amongst my colleagues :-)

-tim

On Tue, Jan 5, 2016 at 12:19 PM, Chris White <[email protected]>
wrote:

> Yep, that does help a lot Tim, thanks!
>
> The variable idea makes a lot of sense and would at least let me cut down
> on the redundancies a bit, I am curious though if you could show how you'd
> do this type of thing with modules instead in a targeted tasks.
>
> This is my first time using Ansible and I'm definitely coming at it from
> the Superlumic angle and working my way outward from there, I haven't
> really dug into Modules yet at all.
>
> If you're curious, my full configuration is here
> <https://github.com/christopherdwhite/superlumic-config>.
>
>
> On Monday, January 4, 2016 at 8:51:45 PM UTC-7, Tim Rupp wrote:
>
>> Hey Chris,
>>
>> I typically use modules to do targeted tasks instead of trying to batch
>> multiple operations into a single task, but in the interest of educating
>> myself, I took a swing at putting your example into a single task. The
>> following should give you some ideas.
>>
>>
>> - name: a play
>>   hosts: all
>>   connection: local
>>
>>   tasks:
>>       - name: TextExpander Settings Directory
>>         file:
>>             path: "/tmp/Application\ Support/TextExpander/"
>>             state: "directory"
>>
>>       - name: TextExpander Settings Symlink
>>         file:
>>             src: "/tmp/Dropbox/TextExpander/Settings.textexpander"
>>             dest: "/tmp/Application\
>> Support/TextExpander/Settings.textexpander"
>>             state: "link"
>>             force: "yes"
>>
>> - name: a play
>>   hosts: all
>>   connection: local
>>
>>   tasks:
>>       - name: TextExpander Settings
>>         file:
>>             path: "{{ item.path|default(omit) }}"
>>             state: "{{ item.state }}"
>>             src: "{{ item.src|default(omit) }}"
>>             dest: "{{ item.dest|default(omit) }}"
>>             force: "{{ item.force|default(omit) }}"
>>         with_items:
>>             - path: "/tmp/Application\ Support/TextExpander2/"
>>               state: "directory"
>>             - src: "/tmp/Dropbox/TextExpander2/Settings.textexpander"
>>               dest: "/tmp/Application\
>> Support/TextExpander2/Settings.textexpander"
>>               state: "link"
>>               force: "yes"
>>
>>
>>
>> The first play is just a mock-up of the example you provided.
>>
>> The second play is the same example (I just changed the directory name to
>> "TextExpander2") with a single task used with a loop and jinja's omit
>> filter. I'm looping over a list of dictionaries and using omit on values
>> that I know may not exist. State always exists.
>>
>> Now, does this make it look cleaner? Well, that's subjective so I'll let
>> you decide. You could take the content in the with_items list and put it in
>> a vars file to make the play itself look smaller (and allow your list of
>> things to grow nearly unbounded).
>>
>> When I run it on my box over here it goes off without a hitch and gives
>> me (what I think) are the results you're looking for
>>
>>
>>
>>
>> SEA-ML-RUPP1:ui trupp$ ansible-playbook -i localhost, ok.yaml
>>
>> PLAY [a play]
>> *****************************************************************
>>
>> GATHERING FACTS
>> ***************************************************************
>> ok: [localhost]
>>
>> TASK: [TextExpander Settings Directory]
>> ***************************************
>> changed: [localhost]
>>
>> TASK: [TextExpander Settings Symlink]
>> *****************************************
>> changed: [localhost]
>>
>> PLAY [a play]
>> *****************************************************************
>>
>> GATHERING FACTS
>> ***************************************************************
>> ok: [localhost]
>>
>> TASK: [TextExpander Settings]
>> *************************************************
>> changed: [localhost] => (item={'path': '/tmp/Application
>> Support/TextExpander2/', 'state': 'directory'})
>> changed: [localhost] => (item={'dest': '/tmp/Application
>> Support/TextExpander2/Settings.textexpander', 'src':
>> '/tmp/Dropbox/TextExpander2/Settings.textexpander', 'state': 'link',
>> 'force': 'yes'})
>>
>> PLAY RECAP
>> ********************************************************************
>> localhost                  : ok=5    changed=3    unreachable=0
>>  failed=0
>>
>> SEA-ML-RUPP1:ui trupp$
>>
>>
>>
>>
>> Hope that helps.
>>
>> -tim
>>
>> On Mon, Jan 4, 2016 at 7:10 PM, Chris White <[email protected]>
>> wrote:
>>
>>> Took a different approach to this and tried to set this up as a Bash
>>> command instead and discovered that it also requires the creation of the
>>> directory structure in a separate step so I'm guessing there's no way to
>>> make Ansible do it if it isn't built directly into the module. Looks like
>>> I'll just need to add a second task unless anyone else has an idea.
>>>
>>> On Monday, January 4, 2016 at 8:02:50 PM UTC-7, Chris White wrote:
>>>>
>>>> So I take it no one else is doing this kind of thing? I pinged Ansible
>>>> on Twitter and they directed me here.
>>>>
>>> --
>>> 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/8244a346-7ea2-4cf1-86c8-10b6796f4b42%40googlegroups.com
>>> <https://groups.google.com/d/msgid/ansible-project/8244a346-7ea2-4cf1-86c8-10b6796f4b42%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/690bb38d-56fc-440c-ac8e-c03d3df44828%40googlegroups.com
> <https://groups.google.com/d/msgid/ansible-project/690bb38d-56fc-440c-ac8e-c03d3df44828%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/CAB0Zv8iUBL9FX%3Dd-wpi4BkwcAhiKmn57b_ACMz%3DBnVtQabYggw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to