Directly execute playbooks

[samatjain]

Were there any plans to introduce an API to Suitable that lets you execute playbooks directly?

E.g.

ansible_playbook = '''
- hosts: all
  tasks:
  - ping:
'''
Api(...).execute_raw_playbook(ansible_playbook, format=YAML)

You could do this by writing the playbook to a file and using Api(..).include_task (I have not tried), but Suitable would really fit some use-cases I have (replacing a bunch of crufty Fabric scripts) if it had an API like this.

Edit: found #9 after opening this, oops! My issue with using the Ansible API directly is that it's explicitly NOT stable, and Suitable's API is (and much more elegant!).

[href]

As I stated before, I'm not convinced this makes much sense, as you can run playbooks using the Ansible CLI, which I assume is stable. Wouldn't it make more sense for your use case to just call the CLI in a subprocess?

[samatjain]

So, just to be clear what I was hoping to find: simplified, programmatic, stable access to the Ansible API.

I'm trying to replace some crufty Fabric 1.x scripts. Migrating to Fabric 2 and patchwork is enough work that I am evaluating other options. Using Suitable's API, keeping the logic in pure-Python, is a option since everything is being rewritten anyway.

However, that script being entirely written in Python has been an issue, especially when people who don't know Python want to edit it. I'd like to refactor some of the tasks out into conventional ansible playbooks (i.e. stuff that someone could Google) so they're a bit more maintainable.

The Fabric scripts do things that are not easy in ansible, at least not without making it significantly more difficult to invoke.

In particular, I want to preserve the fact that all logic is contained in the script. Keeping playbooks external to the script is a headache because of path nonsense that I'd like to avoid.

AFAIK to use the Ansible CLI, the playbooks would have to be written to some temporary location for execution. And unfortunately the Ansible API does not look very stable.

[href]

So, just to be clear what I was hoping to find: simplified, programmatic, stable access to the Ansible API.

Yes and no. Suitable isn't a feature complete stable API to Ansible. It offers access to the most valuable thing Ansible has to offer (imho) - which is the large number of modules available that make it easy to execute common sysadmin tasks. That is it's main goal and it is how it started - I called some Ansible modules from my scripts and eventually factored the repeated code out into Suitable.

This is also the source of my reservation about this feature. I never had a need for this - that's not necessarily a good argument for not including something, it's just that historically I made sure to use everything I put into Suitable to ensure that it's tested against a live environment. I understand what happens with the API in it's current state and I can use it without having to learn Ansible first.

I do however not know enough about playbooks to create an API that could be stable. There's much more machinery involved once we introduce playbooks (variables, configuration files, templates) and that doesn't fit well with the API class that exists currently. A lot of decisions would have to be made about where to draw the lines between what happens in the playbook and what happens in the API.

So currently this is not something I see myself supporting, though I do see your point.

[samatjain]

I was thinking the API I proposed in the OP was minimal and supportable-long term, especially since Suitable more or less does this internally (line 129 of module_runner.py), sans the format conversions.

I can understand what you mean by in-playbook variables and templates (path nonsense)… I'm not sure what to advise there other than limiting the sophistication of playbooks executed via this method (playbook-scoped variables only, no facts, etc).

[href]

It's something to consider and I'll keep this open for others to weigh in. I'm not totally against it, but I won't promise you anything nor will it be solved quickly.

[Azulinho]

I personally have been porting some of my playbooks to python modules/functions, so that I can consume them in a pythonic way.
here's one: https://github.com/pyarchops/tinc

my 'playbooks' then become as short as:
result, logs = pyarchops.tinc.apply(api, config=config)