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

[Simo Sorce]

----- 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.

Simo.