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