New Module Design Question

Archives Ansible Developer
1

Hi All - Question regarding the correct Ansible friendly abstraction of a new module that interacts with a fairly complex API.

I’m working on updating and refactoring NS1’s existing Ansible modules (found here) for submission to Ansible Core. The module I’m working on for the initial PR is ns1_record, which creates DNS records on NS1’s managed DNS platform. All of this functionality is fairly straightforward to include in a single module except for two parameters that can be use with any record: filters and metadata.

Both filter and metadata parameters are arbitrary length lists of individual filter or metadata types that alter the way a record behave. There 15+ filter and metadata types, respectively, each with their own legal values.

In the current API, these lists are created and attached to a record in the same API call that creates or modifies a DNS record. The existing module mirrors this functionality and allows users to attach arbitrary lists to the filter and meta parameters in the same module where they manage records. No checking of these lists is currently done in the module to ensure legal filters or metadata types are used.

Would the correct approach here be to keep this functionality in a single module (adding 15+ choices to the meta and filter parameters to ensure legal values), or should constructing and attaching meta and filter objects to records be abstracted away into separate modules?

Any feedback here is much appreciated!

2

After looking further at some other modules, I can find other examples of modules with parameters that accept lists of user defined keys and values (i.e. the containers param in the ecs_taskdefinition module).

This seems like the simpler route as this is the current state of the existing module and the API would provide descriptive errors if an invalid key was used. Additionally moving filters and metadata to separate modules would increase the number of API calls required to get a record completely configured.

This seems like the direction we should go in, but, any feedback is much appreciated.