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

[Martin Kosek]

On Wed, 2011-12-14 at 12:43 -0600, Endi Sukma Dewata wrote:
> On 12/14/2011 12:53 AM, Martin Kosek wrote:
> >> I found this works ok and adding records is definitely clearer but it
> >> seems odd to add with one command and delete/find with another. I could
> >> get used to it I suppose.
> >
> > Hm, we could add dnsrecord-<rr>-del ZONE RECORD VALUE command, but this
> > would increase the already high number of DNS commands.
> 
> As suggested in the meeting, instead of having a separate command for 
> each type:
> 
>    dnsrecordsrv-add ZONE NAME [srv-specific parameters...]
>    dnsrecordmx-add ZONE NAME [mx-specific parameters...]
> 
> we could use the same command but we specify the type as a parameter:
> 
>    dnsrecord-add ZONE NAME --rec-type=srv [srv-specific parameters...]
>    dnsrecord-add ZONE NAME --rec-type=mx [mx-specific parameters...]
> 
> This will keep the number of commands low regardless of the number of 
> rrtypes we support now or in the future. Same thing for mod and del.
> 
> All type-specific options can be made optional, or we can require some 
> options depending on the type specified. The doc needs to specify which 
> options are needed for each type.
> 
> The interactive mode should still work too based on the type specified. 
> If the user doesn't specify a type the command can even ask for it.
> 
> > Endi and Petr had an idea to add a new --structured option for
> > dnsrecord-find/dnsrecord-show which would show structured DNS records
> > instead of raw DNS records. But I think our current framework is not
> > ready for this. While a raw DNS record is basically one entry item
> > (label : value), structured DNS record is an entry on its own
> > ({label1:value1, label2:value2, ...}):
> >   - dnsrecord-find's output is ListOfEntries, but with use of
> > --structured option it would have to be changed to something like
> > ListOfListsOfEntries
> >   - dnsrecord-show's output would have to be changed with a use of
> > --structured option from Entry to ListOfEntries
> 
> I think we're mixing up several alternatives in the discussion. Never 
> mind about dnsrecord<rrtype>-find/show returning record data in separate 
> entries. I don't think right now it will be a good idea since they are 
> actually attributes (no filter for certain param in the type, no primary 
> key).
> 
> What we're suggesting is the find command should always return a 
> ListOfEntries and the show command should always return an Entry, which 
> will be consistent with other commands. So when you call dnsrecord-show 
> ZONE NAME without --structured, it will return a single Entry like before:
> 
> {
>      idnsname: 'foo',
>      arecord: [
>          '10.10.10.10'
>      ],
>      cnamerecord: [
>          'bar.example.com.',
>          'bar2.example.com.'
>      ]
> }
> 
> But when you specify --structured, it still returns a single Entry 'foo' 
> but the structure of the attributes will change like this (or like the 
> one suggested by Petr):
> 
> {
>      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.'
>          },
>      ]
> }
> 
> If you call dnsrecord-find ZONE --structured the output will be a 
> ListOfEntries like before, but each Entry will have a structure like above.
> 
> > 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.
> 
> Since the 'records' attribute is an array in an Entry, there shouldn't 
> be any issue about uniqueness.
> 
> Also as suggested in my previous email, we can also add a --rec-types 
> parameter to the find/show command to select which rrtypes we want to 
> see in the result. If not specified it should return all types.
> 

I think this all are valid points, I will summarize the proposad
approach to DNS API based on options instead of commands to separate
mail. It is too important to get lost in this long thread :-)

Martin