While working on a PR for the win_dns_record
<https://docs.ansible.com/ansible/latest/modules/win_dns_record_module.html>
module, I ran into a documentation issue that I thought best to ask about,
in case anyone can offer any suggestions or otherwise correct my thinking.
As background, I'm trying to extend the existing module to support
additional DNS record types. Of concern is that the new record types take
*values* that are more nuanced than those currently supported.
---------------
Example #1 (already supported):
- An "A" record is used to map a hostname to an IP address.
- The record's *value* in this case is the IP address itself. This is a
simple (non-compound) value, expressed as a string.
- An appropriate way to document this "value" option in this case would
include type=list and elements=str.
Example #2 (want to add support for this):
- An "MX" record is used to indicate which mail server should receive
email for a domain.
- The record's *value* in this case is a tuple comprised of a *priority*
and a *hostname*. This is a compound value, which I'd *prefer* to
express as a dict (because names are clearer than list offsets).
- An appropriate way to document this "value" option would still include
type=list, but now requires elements=dict (rather than =str) and a
suboptions={...} that is *specific* to MX records.
So the problem comes from wanting to support record types that require
*compound* values. (And note that the specific value *fields* aren't the
same for each record type!).
---------------
As far as I can tell, there is no way to specify "conditional" suboptions,
or even more than one set of suboptions, even if the backend is made smart
enough to handle it (which turns out to be fairly straightforward,
incidentally -- I have no concerns on the *implementation* side).
If true, that suggests I would need to resort to free-form fields, in which
case the *real* documentation exists solely in the examples (which is far
from ideal).
---------------
Am I somehow wrong in assuming that suboptions can't be used the way I
want? Or is there some other way to nuance them? Some way to add
hand-crafted HTML to an option? Other things to try instead?
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-devel/6fc49c33-9973-4f38-99f6-d2140df85f4a%40googlegroups.com.
