'taskify' includes

[bcoca]

Proposal: make include_X behave more like normal tasks

Author: Brian Coca <@bcoca> IRC: bcoca

Date: 2018-13-01

• Status: New
• Proposal type: core design
• Targeted release: future release
• Estimated time to implement: many weeks

Motivation

make task lists are roles more reusable

Problems

• noise, sometimes i just wan the result of a role, not every little thing it does in between
• includes still act mostly like imports not a reusable component, there is no way to handle them as a whole

Solution proposal

Implement a couple of new featuers to the include:

• Add 'flatten output' (single_output option) ... so we ONLY see the success/failure of the input itself
  • default: (modifiable by failed/changed_when)
    • success: all tasks succeded or were skipped
    • failed: 1 or more tasks failed (rescue and ignore_errors are considered success)
    • changed: 1 or more tasks changed

• Allow to register a result (aggregate of all tasks + top level that reflects above)

  - name: using role as example, but this should also work for tasks
    include_role: name=tidy single_output=yes
    result: didittidy
    failed_when: (didittidy['included']|select('failed') > 3)
    vars:
       var1: val1

  feel free to bikeshed on 'single_output' i just can't think of anything better at this moment

Dependencies

• need to be able to ignore callback events specific to the tasks
• need to aggregate results per include

Testing

yes, normal integration tests should suffice

Documentation

in the modules affected

Problems

• stacking
  • include=>include=>include=>include can end up with huge data set, probably ONLY aggregate the data if we know register: is set
  • imports are 'static' and those inside an include can behave odly

[urusha]

-removed-

[bcoca]

@urusha I'm not sure what you mean, those seem like unrelated issues.

[urusha]

Unrelated. Sorry, wrong tab :)

[privateip]

@bcoca does this proposal allow for defining the tasks entry point or does this only work with main.yml

[bcoca]

entry point should not matter, it would affect the role as a whole, but if we make it an option, it will let the user mix/match how he wants it to work in either case

updated proposal and example with 'simple_output'' to clarify my meaning

[chouseknecht]

@bcoca

Seems like a reasonable idea.

[alikins]

If we do this and the role arg spec stuff and contentpath with fully qualified names for roles, that would be really close to allowing:

hosts: myhosts
vars:
  some_var: some_value
  some_other_var: some_other_value
tasks:
   - name: some debug task
     debug:
       var: some_other_var

   # just a regular task
   - file:
        state: dir
        path: /dev/null/somepathwhatever

    # dont get hung up on this particular name format, just need some name/id that
    # identifies this as a role and a particular role. much like 'file:' means the file module
   - roles.mygithubuser.mycollection.myrole:
       some_role_var: blippy
       some_option: "{{some_other_var}}"
     register: the_result_of_myrole

[bcoca]

@alikins that was something i proposed in the past, a bit different as i was using @ to signify 'its a role':,

 - @rolname: 
         tasks_from: x
     vars:
        x: y

It is not something I'm currently aiming for, at this point i just want to take small steps that are useful by themselves but as a whole make roles a lot more reusable.

[zakstar]

Can we also have 'until' for include_X?

[jamescassell]

Can we also have 'until' for include_X?

I tend to use a recursive include when I need this functionality.

[jean-christophe-manciot]

@bcoca

Is this still in the works or abandoned?

[bcoca]

neither, its on wishlist, but no immediate plan

[kunamashina]

This is required, hopefully will be looked into and implemented next year