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. On Sunday, March 17, 2019 at 1:50:22 PM UTC-4, Matthew Burtless wrote: > > 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 <https://github.com/ns1/ns1-ansible-modules>) 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! > -- You received this message because you are subscribed to the Google Groups "Ansible Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-devel+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
