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.
--
Endi S. Dewata
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
