Collection plugins for ara

[hille721]

Based on discussion with @dmsimard and @Thulium-Drake :

Currently the ara plugins are not following the new Ansible way to bundle everything in collections. An disadvantage of this is that using Ara is a bit unhandy as the plugin paths have to be explicitly specified.

This could be easily solved by wrapping the plugins from the Python ara package in plugins in this collection. Afterwards the plugins could be simple enabled by setting:

callbacks_enabled = recordsansible.ara.ara_wrapper

Now it is still unhandy as the ara collection needs to be installed. Thus in a further step we should try to be included in the official Ansible Python package. For that we also need to apply some coding styles on this repo.

• [ ] I will provide a PR with the plugin wrappers
• [ ] Make collection ansible-lint compliant
• [ ] Further needed compliance like ansible-test sanity
• [ ] Whatever is further needed to become a collection

[dmsimard]

Hi, thanks for creating the issue !

I want to summarize my understanding to make sure we are on the same wavelength:

We'll continue shipping the "real" Ansible plugins as part of the ara python package.

This means pip install ara && export ANSIBLE_CALLBACK_PLUGINS=$(python3 -m ara.setup.callback_plugins) continues to work without requiring the collection to be installed or introducing a dependency on galaxy.

Now, it would be nice if the people who installed the collection, they could use the fully qualified collection name path to the plugins in order make ansible-lint happy and have a static configuration in ansible.cfg files.

For example:

    - name: Retrieve the current playbook so we can get the ID
      ara_playbook:
      register: playbook_query

    - name: Save the playbook id so we can re-use it easily
      set_fact:
        playbook_id: "{{ playbook_query.playbook.id | string }}"

    - name: Recover data from ARA
      set_fact:
        playbook: "{{ lookup('ara_api', '/api/v1/playbooks/' + playbook_id) }}"
        tasks: "{{ lookup('ara_api', '/api/v1/tasks?playbook=' + playbook_id) }}"
        results: "{{ lookup('ara_api', '/api/v1/results?playbook=' + playbook_id) }}"
        hosts: "{{ lookup('ara_api', '/api/v1/hosts?playbook=' + playbook_id) }}"

would become something like:

    - name: Retrieve the current playbook so we can get the ID
      recordsansible.ara.playbook:
      register: playbook_query

    - name: Save the playbook id so we can re-use it easily
      ansible.builtin.set_fact:
        playbook_id: "{{ playbook_query.playbook.id | string }}"

    - name: Recover data from ARA
      ansible.builtin.set_fact:
        playbook: "{{ lookup('recordsansible.ara.api', '/api/v1/playbooks/' + playbook_id) }}"
        tasks: "{{ lookup('recordsansible.ara.api', '/api/v1/tasks?playbook=' + playbook_id) }}"
        results: "{{ lookup('recordsansible.ara.api', '/api/v1/results?playbook=' + playbook_id) }}"
        hosts: "{{ lookup('recordsansible.ara.api', '/api/v1/hosts?playbook=' + playbook_id) }}"

Same thing for ara_record which would become something like recordsansible.ara.record.

As you mentioned, the callback could then be configured via an ansible.cfg, though I would probably call it recordsansible.ara.callback instead of recordsansible.ara.ara_wrapper.

I am OK with this, we can do it and thanks for suggesting it.

I would split the "inclusion in the ansible package" into a different issue as I think that's a topic on it's own but in the meantime we can start with the wrappers.

[hille721]

Same thing for ara_record which would become something like recordsansible.ara.record.

I would not do this but stick with existing names, thus that playbooks which are already there will still work. Thus names would be:

• callback: ara (recordsansible.ara.ara)
• lookup: ara_api (recordsansible.ara.ara_api)
• action: ara_playbook (recordsansible.ara.ara_playbook), ara_record (recordsansible.ara.ara_record)

I also realized that currently we somehow misuse the action plugins. Normally there should be a module with the same name for a action plugin. All the documentation thing is then also done in the module and the action plugin will automatically called when the module with same name is be used.

[Thulium-Drake]

I'm a bit on the fence, I'm a sucker for eyecandy, so I like the shorter, deduped names. And they have the benefit of not conflicting at all with the existing setup. OTOH, not having to rename also is a benefit.

Though, speaking for myself, I don't mind renaming a few modules in my playbooks (Ansible Lint will probably complain about them not being FQCN anyway)