Feature Request: Generic API module

[fhlmbrg]

Have you ever considered creating a generic "Panos API module", which you allows you to configure things not covered by the current set of Ansible Panos modules?

Take the Cisco ACI modules as an example. Instead of having to create hundreds of modules to cover all possible ACI scenarios, @dagwieers created the aci_rest module to do just that. It supports XML, JSON and YAML as the body input.

See https://docs.ansible.com/ansible/devel/modules/aci_rest_module.html and https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/network/aci/aci_rest.py .

The alternative is to start building custom modules or hacks using uri. Take sub interfaces #194 which is still not supported. You could use uri like so:

  tasks:
    - name: Add a layer 3 subinterface
      uri:
        url: http://{{ panos_provider.ip_address }}/api/?key={{ panos_provider.api_key }}&type={{ req_type }}&action={{ req_action }}&xpath={{ xpath }}
        method: POST
        body: "{{ uri_body }}"
        return_content: true
        validate_certs: false
      vars:
        req_type: config
        req_action: set
        xpath: /config/devices/entry[@name='localhost.localdomain']/network/interface/aggregate-ethernet/entry[@name='{{ item.key }}']/layer3/units
        uri_body: |
          element=
          <entry name='{{ item.key }}.{{ item.value.tag }}'>
            <tag>{{ item.value.tag }}</tag>
            <ip>
              <entry name='{{ item.value.ipv4 }}/{{ item.value.prefix }}'/>
            </ip>
          </entry>
      loop: "{{ interfaces | dict2items }}"
      register: output

.. but I would much prefer an official Panos module instead :-)

[ishuguru]

This was exactly what i had in mind around my question here: #373 (comment)

[dagwieers]

Beware that the official position of the Ansible core team is that they do not want wrappers around APIs, but instead high-level interface modules. I don't agree with that position obviously, and for ACI it could mean thousands of modules (of which most are niche modules).

We also see in the field that most companies start off with the basic modules to learn the product, but over time (or when they hit needs that are not fulfilled by standard modules) switch partly and eventually completely to the flexibility of aci_rest.

This flexibility has also to do with the limitations of Ansible itself, which is not designed for managing tens of thousands objects in iteration. Something I would like to fix with: ansible/proposals#71 (comment)

But it appears I stand alone in this analysis.