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

[Dmitri Pal]

On 12/14/2011 03:02 PM, Simo Sorce wrote:
>
> ----- Original Message -----
>> 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.
> I disagree, it will make things a lot more cumbersome and will require
> entire new commands if we want to add new types in future. It does not
> scale well and it is potentially open bounded.
> For the help issue I am sure we can figure out a way to pass --rec-type
> to help if really needed, otherwise help can simply list all know syntaxes.
>

The whole point of this work to decompose things and make them simpler.
One command with dozens of options is much harder to use.
I stand on my own point but we should ask community.

> Simo.
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


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