[Freeipa-devel] Optionistic approach for new DNS API

[Endi Sukma Dewata]

On 12/15/2011 4:03 PM, Martin Kosek wrote:
>> If we use the raw data, it should be specified as an option instead of
>> an argument:
>>
>>     ipa dnsrecord-mod ZONE NAME --type=mx \
>>       --rec-data="10 server1.example.com." --new-preference=20
>
> I was also thinking about using current param "--mx-rec":
>
>      ipa dnsrecord-mod ZONE NAME --mx-rec="10 server1.example.com." \
>        --mx-preference=20
>
> But this would be a misuse and unexpected behavior. A new option would
> be better for that.

I'm OK with either options. The help doc describes the --mx-rec option 
as a "comma-separated list of MX records". It doesn't say how the 
parameter should be used. We could say the mod command can be used in 2 
different modes.

In the first mode (the original) the command modifies the entire record 
object and the --<RRTYPE>-rec is used to specify the new records.

In the second mode the command modifies a record specified in the 
--<RRTYPE>-rec. It also syntactically means we could perform the same 
modification against several records at once, although I'm not sure if 
it makes sense:

   ipa dnsrecord-mod ZONE NAME \
     --mx-rec="10 server1.example.com.,10 server2.example.com."
     --mx-preference=20

> Current command can do that:
>      ipa dnsrecord-del ZONE NAME --mx-rec="10 server1.example.com."
> We have this behavior for free.

This is probably another reason to use the same --mx-rec option in mod.

>> Alternatively we can use separate option for each parameter:
>>
>>     ipa dnsrecord-mod ZONE NAME --type=mx \
>>       --preference=10 --exchanger=server1.example.com. \
>>       --new-preference=0
>>
>>     ipa dnsrecord-del ZONE NAME --type=mx \
>>       --preference=10 --exchanger=server1.example.com.
>>
>> Or we can support both.
>
> I think I would implement the first option first. We can extend if we
> see it is useful. My point is that I don't think use would bother
> constructing structured DNS record from its options in dnsrecord-del/mod
> (fill --preference and --exchanger) but rather copy&paste raw DNS value
> or use the interactive mode.

It might be useful for someone writing an application using the CLI. 
This way we don't need to know the order of the parameters.

It's a low priority, but we should plan what parameter names we're going 
to use in the future. If now we use --mx-preference to specify the new 
value, later when we implement the new mechanism we will need to use 
something like --mx-old-preference to specify the old value. I'd rather 
use --mx-new-preference for the new value.

>>> - SHOW and FIND commands do not need this new --type parameter
>>
>> We can also add --types to specify the record types we want to get back
>> in the result. This could be useful in case we want to refresh a certain
>> table only in the record details page. Low priority.
>
> Ok, noted as an idea for enhancement. I would rather like to create a
> functional minimalistic API first and add all the bells and whistles
> later when we see it is useful.

OK.

>> BTW, I'd rather use --rec-type instead of just --type because 'type'
>> seems to be more generic. In case a certain DNS record type also has a
>> 'type' parameter, it might conflict with that. Another possibility is to
>> use a prefix for all type-specific options, e.g. --mx-preference.
>
> Actually, I was discussing this with Honza today. The problem is that we
> can't add conflicting options to one command (e.g. --preference for MX
> record and --preference for KX record). We would have to use
> --mx-preference and --kx-preference anyway.

It probably depends on how it's actually implemented. I suppose it's 
possible to keep a separate list of options for each type-specific 
command, then merge the lists for the main dnsrecord-add/mod/del command 
while removing duplicates. But using prefix is OK too.

> This would also remove the necessity to use --rec-type at all. I think
> we could detect the type from the options that were passed. I.e. when
> the following command is passed:
>
>     ipa dnsrecord-add ZONE NAME --mx-preference=0 --mx-exchanger=server1.example.com.
>
> We know that MX record is being created.

Without the --rec-type, it's syntactically possible to add/mod/del 
multiple RR types at once. I'm not sure if we want to support that:

   ipa dnsrecord-mod ZONE NAME \
     --mx-preference=0 --mx-exchanger=server1.example.com \
     --mx-new-preference=1
     --kx-preference=0 --kx-exchanger=server1.example.com \
     --kx-exchanger=server2.example.com

>>> - ADD command:
>>>     - when no option is passed to dnsrecord-add command, it may ask for
>>> --type and then for the options specific for the particular type
>>> - MOD command:
>>>     - when no option is passed to dnsrecord-mod command, it may provide a
>>> list of current DNS record values and ask for specific DNS record parts
>>> to be changed for chosen value
>>> - DEL command:
>>>     - when no option is passed to dnsrecord-del command, it may provide a
>>> list of current DNS record values remove the chosen value
>>
>> For consistency the mod&  del commands can also ask for the type, then
>> show the list of records in that type. This way the list can be shown in
>> a nicely formatted table rather than just raw data.
>
> IMO the interactive help I described is more effective - use just has to
> choose a record and start modification for a specific RR type. With your
> proposal, he would have to choose a type, then choose a record of that
> type and then start the modification - 2 steps instead of 1.

The difference is not that big. Also if we keep the --rec-type option we 
can skip the first step:

   ipa dnsrecord-mod ZONE NAME --rec-type=mx

> (And I don't think that formatting nice tables with records in CLI
> would be a priority).

Table is a compact way to show the data while still describing what the 
values in the raw data mean.

   No.  Preference   Exchanger
   --------------------------------------
   1.   10           server1.example.com.
   2.   20           server2.example.com.

Without table we might have to label each value:

   Record #1
   Preference: 10
   Exchanger: server1.example.com.

   Record #2
   Preference: 10
   Exchanger: server2.example.com.

or just show the raw data without labels:

   1) MX: "10 server1.example.com."
   2) MX: "20 server2.example.com."
   3) SRV: "0 100 464 ldap"

My preference would be using the table, but the other options are still 
acceptable.

-- 
Endi S. Dewata