Hi Grzegorz,
You might want to look at the v2 work going on, which will implement some
of the features you've noted above (include + with_items and runtime
evaluated includes, at least at the task level).
Also, another feature we're working on in v2 is the concept of "blocks",
which will essentially allow better grouping (and error handling) for
tasks. An example of a block is:
begin:
- name: task 1
...
- name: task 2
...
rescue:
- name: rescue task 1 (runs when any task in the main block fails)
...
end:
- name: some cleanup task that is always run
...
Blocks already support tags/when statements, but do not currently support
many of the other task-level options like sudo/sudo_user. If we want to,
they could be extended to include those as well without too much effort I
think, if that's something users are interested in. We're using the
ruby-ish syntax here due to internal variable names, but we have talked
about switching this back to the more pythonic try/except/finally syntax.
I plan on using my speaking slot for AnsibleFest London next week to run
over the new features in V2, so stay tuned for a slide deck to see what
else is going on in the new codebase (or even better, buy tickets!).
Sorry this degenerated into a "hey, look at v2!" response, but I really do
think it does (or will) fit what you're trying to accomplish here, and
we're getting very close to opening up contributions there as it's nearing
critical mass on feature support.
Thanks!
On Tue, Jan 27, 2015 at 12:07 PM, Grzegorz Nosek <[email protected]>
wrote:
> Hi,
>
> I just wrote a module that allows for DRYer playbooks, without repeating
> sudo/when/with_items etc. over and over again in a play (or making lots of
> small included files).
>
> It's on github: https://github.com/gnosek/ansible-play and comes with a
> couple examples, so I'll just mention it allows an include/with_items
> combination, runtime-evaluated includes and other funny things :)
>
> Comments, patches, flames appreciated.
>
> Also, I'd love to see some version of this upstream, even though it does
> work around the API in a rather crude way and would benefit greatly from
> some minor changes in Ansible core.
>
> Best regards,
> Grzegorz Nosek
>
> --
> 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/d45e953a-58a6-4431-836b-5cdf58af5721%40googlegroups.com
> <https://groups.google.com/d/msgid/ansible-project/d45e953a-58a6-4431-836b-5cdf58af5721%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/CAMFyvFi6gTwnn9Hxk5%2BZU4PAvfJZ8x91GzGE2EgHjhynPCSDKw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
