Feature request: Show playbook tasks as subactions (like a workflow)

[cognifloyd]

At some point in the future, it would be nice to have ansible playbooks integrate more directly with the StackStorm infrastructure. A playbook is essentially a special kind of workflow that runs through the ansible 'engine'. It would be nice to show the tasks as sub-actions in st2web and from the cli.

That would allow, for example, quickly seeing which task a playbook failed on. You can get that by looking at the stdout embedded in the json output. But it'd be nice to have this feel more like a first class citizen.

This is probably a very significant change that would probably require additional support from within st2.

It might also require switching the action_runner (at least for playbooks) from local-shell-script to python-script to hopefully have easier integration with the rest of the st2 apis.

Maybe that would mean that the playbook would be running with a special callback or with verbose turned on so that StackStorm could get a deeper view into what happened in each task.

So, does anybody else like the idea of making playbooks feel more like a special kind of workflow?

[cognifloyd]

Maybe this would need to be implemented as an action-runner: the ansible-playbook action runner.

It would be a good way to experiment with adding action-runners outside of the core st2. That could help with solidifying the API and writing docs.

An ansible-playbook action-runner would mean that playbooks could be first-class citizens. Instead of embedding an ansible-playbook action in a workflow (where parameters can be defined), the playbook can, itself, be an action (hopefully with tasks=subactions) including default extra_vars, and defining the inventory and other parameters.

[cognifloyd]

I guess I should also mention the idea that @nmaludy and I were chatting about in slack:
An ansible module for running stackstorm actions.

That module could either require running within the action_runner, or get auth tokens passed in (via env?) to allow it to use StackStorm's API to add actions (or something like that).

lookups would also be needed to allow looking up stuff from the datastore or getting info about another execution or the list of timers/actions/packs/etc or something like that.

@LindsayHill Would kicking of st2 actions from inside a playbook that is running from a playbook action-runner feel less inception-like to you? 😉 then again, it could still allow st2 - playbook - st2 - playbook - st2 ....

[arm4b]

@emptywee solves this "subactions" problem by dividing a big playbook into a smaller logically independent reusable Ansible playbooks. With that, you get the result from each playbook early and based on execution result enhance it with mistral logic.

@cognifloyd Of course, that's not exactly what you're describing, but still better than nothing.

At the moment I'm not sure if we'd prefer to dive deeper into Ansible APIs and modify st2 internals to support something like this. That's exactly what we tried to avoid by adding simple as possible integration pack as a wrapper around Ansible CLI. And we won here, because Ansible API changed signifficantly several times since the pack implementation. We couldn't react on such changes really fast, add here real world problems when people are using different Ansible versions with different APIs/functionality.

But yeah, theoretically with a non-breaking addition on top of existing pack (like Ansible callback plugin) this could work. Depends on implementation, - some research is needed. So if someone feels motivated to experiment, - we welcome that 👍

Talking about the Ansible modules, this is related to ansible-st2 repo, see: StackStorm/ansible-st2#108 discussion for st2 K/V lookup plugin and StackStorm/ansible-st2#74 discussion for pack install Ansible module.
If you have any ideas, - please feel free to describe your proposals about Ansible plugins/module there.

@cognifloyd And thanks for starting this discussion, - it's a good start 😉