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

[Martin Kosek]

On Tue, 2011-12-13 at 11:46 +0100, Petr Vobornik wrote:
> On 12/12/2011 05:26 PM, Endi Sukma Dewata wrote:
> > On 12/12/2011 7:32 AM, Petr Vobornik wrote:
> >>> 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
> >>
> >> I like this option better than the second one. It seems clearer to me.
> >>
> >> Just from UI perspective (no change in commands): I would show only the
> >> the tables which have some values - to let the page be shorter and
> >> clearer. This will require an add button in the facet header - similar
> >> dialog with type selection as in add in search facet except that the
> >> idnsname would be implied.
> >
> > The thing with this is that suppose you are looking for a certain type
> > and that type doesn't exist in that particular record, you would have to
> > look at the entire page before you know it doesn't exist. But if we show
> > empty tables, once you see the table you know the record doesn't have
> > the type you're looking for.
> 
> My assumption was that there wouldn't be many values of different types 
> for one record so it wouldn't be a problem. Probably not a correct 
> assumption...
> >
> > Maybe we can hide the table but still show the table title (i.e. the
> > type) and an Add button next to it?
> 
> Sounds like a reasonable compromise.
> >
> >>> 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.
> >
> >> To avoid this it would be nice to have a method like dnsrecord-find ZONE
> >> NAME (ie this one with new option) which would return the record with
> >> data structure similar to dnsrecord<RR>-show. For example (content of
> >> result):
> >> [ //record array
> >> {
> >> idnsname: 'foo', //name
> >> arecord: [
> >> {
> >> arecord: '10.10.10.10', //raw
> >> ip_address: '10.10.10.10'
> >> }
> >> ],
> >> cnamerecord: [
> >> {
> >> cnamerecord: 'bar.example.com.', //raw
> >> hostname: 'bar.example.com.'
> >> },
> >> {
> >> cnamerecord: 'bar2.example.com.', //raw
> >> hostname: 'bar2.example.com.'
> >> },
> >> ]
> >> }
> >> ]
> >>
> >> This way we would get all info we need without calling batch with 20
> >> commands or calling dnsrecord-find and then batch with 1-20 commands.
> >
> > Yes, it would be great to have something like that. But the extra NAME
> > argument above could be confused with search filter for dnsrecord-find.
> 
> My bad, I accidentally wrote dnsrecord-find instead of dnsrecord-find. 
> But the idea of the structure remains and it could be beneficial in find 
> command (search facet) too. In the case if we decide to show formatted 
> values in the table.
> 
> > It might be better to use an additional flag to determine the output
> > format (like --raw), something like this:
> >
> > ipa dnsrecord-find ZONE --structured
> > ipa dnsrecord-show ZONE NAME --structured
> 
> Yes, this I had in mind by the "new option".
> >
> > The structure could also look like this (but either way will work):
> >
> > [
> > {
> > idnsname: 'foo',
> > records: [
> > {
> > type: 'a',
> > data: '10.10.10.10',
> > ip_address: '10.10.10.10'
> > },
> > {
> > type: 'cname',
> > data: 'bar.example.com.',
> > hostname: 'bar.example.com.'
> > },
> > {
> > type: 'cname',
> > data: 'bar2.example.com.',
> > hostname: 'bar2.example.com.'
> > },
> > ]
> > }
> > ]
> >
> > In this case the UI won't use the dnsrecord-<RRTYPE>-show/find command,
> > but it might still be useful for people using CLI. Or instead of that we
> > could have another option to specify which types you want to get.
> >
> > ipa dnsrecord-show ZONE NAME --types=a,cname --structured
> >
> 
> 

I was thinking about --structured option too, I wrote some info in a
response to Rob's mail. But the thing is that --structured option
changes the command's output structure too much. One command could
return both Entry and ListOfEntries which is not good IMO.

Another problem I see is that different RR types have parts with the
same name (e.g. "preference" is both in MX, KX and NAPTR records). If
any record could appear in an output entry, we would break current rule
that every output parameter in an entry is uniquely defined. Though this
issue could be solved with a prefix for every structured DNS record
part, i.e. KX record would have "kxpreference" and "kxechanger" parts.

Martin