[Freeipa-devel] Structured DNS record API proposal

[Endi Sukma Dewata]

On 9/20/2011 6:15 AM, Martin Kosek wrote:
>>> ACK.  Proposal looks like it will work fairly easily with the UI.
>>> We'll have to make some chagnes due to the Add doing something
>>> different based on the type, but that is the case anyway.
>>
>> Yes, I was thinking how can we integrate this new API to WebUI. AFAIK
>> you use dnsrecord-add $ZONE $REC --a-rec=... --mx-rec=... for adding a
>> new DNS record and dnsrecord-mod $ZONE $REC --mx-rec=... when for
>> example the mx record is being modified. All MX values (even the
>> unmodified ones) are passed to dnsrecord-mod.
>>
>> 1) I was wondering how the new dnsrecord-<rrtype>-add commands can be
>> used. I suppose WebUI will know a list of DNS record types with these
>> new structured commands and offer the user new window to add a record
>> for these types instead of typing them directly to the text box as it is
>> now.

When adding a DNS record the user will specify the name and the type, 
then the UI will show a set of fields based on the selected record type.

So instead of a generic 'data' field like below (click Add):

http://edewata.fedorapeople.org/freeipa/install/ui/index.html#dns=dnszone&identity=dns&navigation=identity&dnszone-facet=default&dnszone-pkey=ayoung.boston.devel.redhat.com

it will be similar to Permissions (click Add):

http://edewata.fedorapeople.org/freeipa/install/ui/index.html#rolebased=permission&ipaserver=rolebased&navigation=ipaserver

The UI will use the type to pick the correct dnsrecord-<rrtype>-add 
command and each parameter in that command will have a corresponding 
field to enter the value.

>> 2) But my main concern here is how the modification of current DNS
>> records should work. Say, we have 2 MX records for example.com. How can
>> we modify one of it in a new structured interface?
>>
>> We would have to implement dnsrecord-mx-show method so that you can fill
>> all the text areas (preference, mailserver). Question is how to refer
>> the value we want to show since DNS records are multivalued. We could
>> pass --dnsrecord="..." with DNS record value, e.g. "0 mx.example.com."
>> and then use the same value for dnsrecord-mx-mod. The whole command
>> sequence would look this way:
>>
>> dnsrecord-find example.com      -- get all DNS records for example.com
>> dnsrecord-show example.com @    -- show DNS records directly in the zone
>> NS: "ns.example.com"
>> MX: "0 mx1.example.com."
>> MX: "1 mx2.example.com."<<  user wants to modify this one ->  new window

I think for each record value the primary keys are the zone name, record 
name, and the value itself. To simplify operations, we should use the 
value as a single string. For CLI, users can copy & paste the value more 
easily.

For UI it depends whether (1) we're going to keep the current edit page 
where all records with the same name are considered a single entry, or 
whether (2) we're going to edit each record value in a separate page. 
See ticket #1478.

If we stay with (1), the link to the edit page consists of zone name and 
record name only. But if we pick (2) the link consists of zone name, 
record name, value, and type (which can be obtained from -find output).

>> dnsrecord-mx-show example.com --dnsrecord="1 mx1.example.com."
>> PREFERENCE: 1	<<  user modifies this to 0
>> MAILSERVER: mx2.example.com.

For consistency, the record value should be specified as an argument 
instead of an option (like in automount). So it will be like this:

dnsrecord-mx-show "example.com" "@" "1 mx1.example.com."
PREFERENCE: 1
MAILSERVER: mx2.example.com

If we stay with (1) the UI will have to call the dnsrecord-<rrtype>-show 
for each value to get the value of each fields. The UI will need to 
implement a new widget (or section) that can handle multiple fields 
which will be duplicated for each value.

The edit page for (2) is much simpler since it only needs to handle a 
single type at a time. The output of the -show command will be used to 
populate each field.

>> dnsrecord-mx-mod example.com --dnsrecord="1 mx1.example.com." --preference=0

When updating the value, option (1) is a bit more complicated because 
the UI will have to find the dirty record and then find the dirty field. 
Option (2) is simpler because it will only need to find the dirty field, 
but both will execute the following command:

dnsrecord-mx-mod "example.com" "@" "1 mx1.example.com." --preference=0

I think option (2) is more clear to users because we only have to 
introduce 2 concepts: zone and record (which is the individual value). 
With option (1) we will have to explain the underlying LDAP entry that 
will be deleted automatically when the last record value is deleted.

-- 
Endi S. Dewata