[Freeipa-devel] [PATCH] [WIP] 172+173 Create per-type DNS API

[Endi Sukma Dewata]

On 11/28/2011 10:35 AM, Martin Kosek wrote:
> I have prepared a working prototype of the new structured DNS API. It
> may still have rough edges (and unit tests are not ready), but it will
> provide a base for discussion and for WebUI folks - so that they can
> start development of the new DNS WebUI API.
>
> The patch takes advantage of the DNS refactor I did in 172. For all
> supported non-DNSSEC RR types, the following commands are available:

For the rest of the record types will there be new commands like below 
eventually or should we use the dnsrecord command?

> dnsrecord<RRTYPE>-show ZONE NAME
> dnsrecord<RRTYPE>-add ZONE NAME
> dnsrecord<RRTYPE>-mod ZONE NAME VALUE

Here's how the commands can be used in the DNS records list page:

http://edewata.fedorapeople.org/freeipa/install/ui/#dns=dnszone&identity=dns&navigation=identity&dnszone-facet=default&dnszone-pkey=example.com

As discussed in ticket #2094 we will add paging support for this page. 
This is done by calling dnsrecord-find --pkey-only to get all primary 
keys, then call a batch of dnsrecord-show to get full data of the 
records being displayed in the current page. I don't think we want to 
use the new dnsrecord<RRTYPE>-show here because we want to get all 
record types and since the space is limited we will just show the raw data.

Click the Add link on the top of the page. The dialog box could be 
modified such that when you select a Record Type instead of showing the 
same Data field it will show the proper fields for the selected type. 
Then when you submit it will call the new dnsrecord<RRTYPE>-add command.

Also discussed in #2094, we'll only have one checkbox for each record 
name instead of one for each value. So in this page we can only delete 
the entire record entry. This will be done using the existing 
dnsrecord-del command.

And then the details page:

http://edewata.fedorapeople.org/freeipa/install/ui/#dns=dnsrecord&identity=dns&navigation=identity&dnsrecord-facet=default&dnsrecord-pkey=testrec&dnszone-pkey=example.com

Right now we use a single text field for each raw data. The first option 
is we could modify this page to use a table for each type, similar to 
HBAC/sudo rule. For example:

  SRV Records

   x | Priority | Weight | Port | Target  [Delete] [Add]
  -------------------------------------------------------
   x | 0        | 100    | 88   | test

The content of the table will be obtained using the new 
dnsrecord<RRTYPE>-show. The add dialog will show the fields for the type 
and it will call the new dnsrecord<RRTYPE>-add command. Deletion will be 
done using the existing dnsrecord-del command.

The other option is to keep the existing style (without tables) but 
instead of a single text field for each record value we will show the 
values in separate fields. For example:

  SRV Records

  Target:   [test     ]  Port:   [88     ]   [Delete]
  Priority: [0    ]      Weight: [100    ]

  [Add]

When you click Update, the UI will have to translate the changes into 
add, modify, and delete operations. The add and modify will be done 
using the new dnsrecord<RRTYPE>-add/mod command. The delete will be done 
using the existing dnsrecord-del command.

Note, regardless of these options when you open the details page the UI 
could execute up to 20 dnsrecord<RRTYPE>-show operations since there are 
20 possible record types currently listed in the UI.

> 1) The commands return a list of structured records (just like *-find
> commands) instead of returning just one record. I thought that it may be
> more usable this way and consistent with dnsrecord-add/mod/show commands
> behavior which returns all records too. Otherwise, we would have to
> change the show command API and add VALUE argument, which would specify
> a value to be displayed:
> dnsrecord<RRTYPE>-show ZONE NAME VALUE

I think for consistency it would be better to call this command 
dnsrecord<RRTYPE>-find since it returns multiple entries. We might also 
be able to add filters in the future.

> 2) Raw DNS record value is in the output too. I though it would be
> useful to see the raw DNS record value + its parts at one place.

Yes, the raw value will be needed for calling dnsrecord<RRTYPE>-mod or 
dnsrecord-del command.

> 3) The commands are in format dnsrecord<RRTYPE>-cmd, for example
> dnsrecordmx-add. I think dnsrecord-mx-add may be more readable. If we
> want to go this way, I would have to bend the server framework a little
> which parses an LDAP object from the command name (LDAP object name is
> dnsrecordmx in this case). This is doable, although I am not sure if
> this does not have some implications in WebUI side.

I agree, the extra dash would be better. When calling a command the UI 
concatenates entity name and method name with an '_'. In this case the 
entity name will remain dnsrecord and the RRTYPE will be prepended to 
the method name.

Btw, patch #175 causes a build break:

ipalib/parameters.py:718: [E1101, Param.normalize] Generator 
'__unicode_csv_reader' has no 'next' member

-- 
Endi S. Dewata