🤔 Consider the priority of Info modules

[displague]

SUMMARY

We've noticed that when _info modules do not exist for a resource, users quickly and rather easily adopt the HTTP URLLib pattern of consuming the API within Ansible.

In many ways, the Ansible collection strives to be unopinionated and act as a passthru to the upstream API. There are several ways, however, in which the collection tries to simplify API usage patterns to provide a more consistent interface:

• HTTP Headers (UserAgent, X-Auth-Token, Content-Type and Accept)
• Future: additional and alternate headers needed for authentication and access to other Equinix APIs
• Future: token requests (OAuth Client Credential flow)
• Future: "helpers"
• Pagination, Sort, and filtering parameters
• Predictable resource access conventions
  • modules with common accessor names and common fields
  • _info modules

Through User-Agent headers, we have insights into what modules are being used against the Equinix Metal APIs. We know that URLLib is a popular choice, especially when a first party module does not exist.

We would like to explore the benefits of these sorts of modules to help us prioritize the addition _info modules.

• Is there a direct user benefit to having create/read(import)/update/delete modules and info (read/list) modules created at the same time?
• Should we wait until an _info module is requested before implementing it?
• Should we recommend users adopt HTTP URLLib based solutions in the interim?
• Does this impact first-party adoption later?

In the URLLib consumption model, we would have different usage patterns between Metal, NE, Fabric, etc. What kind of experience does this create?

See https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_best_practices.html#scoping-your-module-s for advice that applies to this topic.

ISSUE TYPE

• Research

COMPONENT NAME

Future Info modules.