Hi Dave,
On 02/19/09 22:48, Dave Miner wrote: > A couple of comments in-line: > > jan damborsky wrote: >> Hi Sundar, >> >> I have been thinking about support for unicast DNS part (section 1.2) >> and it seems we would need to provide option for specifying DNS >> domain for unicast DNS, since DNS server might reside in different >> domain than AI server, for instance >> >> # installadm create-service [-u domain] ... >> >> '-u' would be optional and its presence would determine if unicast >> DNS is to be used. If not provided, unicast DNS wouldn't be taken >> into account. >> >> I am then thinking if this API enhancement might be sufficient >> for incoming release - additional options might not be needed >> for now with respect to support for unicast DNS and introducing >> fallback mechanism (when neither unicast nor multicast DNS is >> available). >> >> Behavior of AI server and AI client might be following: >> >> AI server - installadm create-service >> ------------------------------------- >> >> * if '-u domain' provided, create service with support for unicast DNS, >> display appropriate PTR & SRV records which need to be added to DNS >> database >> >> * if multicast DNS available, register the service using multicast DNS. >> Otherwise inform user that multicast DNS feature is not avialable. >> >> * add appropriate options specifying service location to configuration >> files (menu.lst, install.conf) for fallback mechanism >> >> AI client behavior during service discovery phase >> ------------------------------------------------- >> >> * if service unicast DNS domain provided, look up service using >> unicast DNS. DNS domain would be specified as another option in >> configuration file (menu.lst or install.conf), not determined >> from DHCP DNSdmain option, since this might be different, something >> like >> >> install_service=_install_service_64501,install_service_domain=ai_caiman.org >> >> > > It appears that you'd be forcing a domain to be specified and stored > in the configuration file in all cases, which seems unnecessary; if > the site wants to place the records in the standard domain, why > shouldn't we use DNSdmain when an override is not supplied? That is a good point. If user doesn't specify domain (or specify default), then DNSdmain would be picked up: * default (pick up the one from DNSdmain): install_service_domain=default * user specified install_service_domain=ai-caiman.org. Presence of 'install_service_domain' option would let AI client know that unicast DNS should be used. In order to avoid potential confusion, trailing '.' would indicate that install_service_domain contains DNS domain name. > >> >> * if searching using unicast DNS fails or DNS domain not provided, >> try to look >> up service using multicast DNS >> >> * if it fails, contact AI webserver directly using service location >> provided, the option might be >> >> install_service_location=machine:port >> >> Since 'machine:port' is now generated by AI server when service is to >> be created, I think it wouldn't be necessary to specify it on command >> line. >> >> >> Limitations: >> ------------ >> >> * If unicast DNS is required, domain always has to be specified. If >> it turns out to be inconvenience for this release, we might add >> support for 'default' or 'current', like '-u default' >> > > Why not "-u" without an argument? I would prefer this, but I saw message from Frank that "option arguments should not be optional". Frank, could we declare <domain> in '-u <domain>' optional ? Or would you recommend to work out some keyword for the case when default should be picked up ? > >> * AI server always tries to register service using multicast DNS. >> I think this is a good default behavior, since it would be one >> of fallback mechanisms, when unicast DNS is unavailable. I am >> not sure, if there might be cases when this is not desired >> > > I think a flag to disable multicast registration would be desirable > for some administrators. It would also be useful in some test > scenarios where you're trying not to interfere with an already-running > infrastructure. You are right - then that sounds like a good things to have. I am thinking about following possibilities: '-u <domain>' - unicast & multicast '-U <domain>' - unicast only or '-u <domain> -m' - unicast & multicast '-u <domain>' - unicast only or '-u <domain>' - unicast & multicast '-u <domain> -M' - unicast only, multicast disabled or ? Maybe Frank might have some preference, what the suitable approach to follow might be. Thank you very much for comments, Jan
