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

[Dmitri Pal]

On 12/14/2011 01:43 PM, 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.
>
But as Martin mentioned on the call we loose help capabilities and make
things really more complex.
My vote would be to have separate commands. IMO it is better from
usability point of view.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/