jan damborsky wrote: > 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. Currently we find unused port numbers and start AI web server. When it comes to unicast, we should allow user to use the same well known port for the service. Otherwise preconfiguring or replicating same DNS entries difficult. I would like us to take port numbers to start web servers in the case of unicast setup. >>> >>> 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. I am assuming unicast and multicast setup is mutually exclusive. If the unicast option is given in 'create-service', then it will setup only unicast. >>> >>> * add appropriate options specifying service location to configuration >>> files (menu.lst, install.conf) for fallback mechanism This may be setup in both unicast and multicast options. >>> >>> 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. See the comments above. For muticast, we can generate a port number. For unicast, provide an option for the user to provide a port number. >>> >>> >>> 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 Can we treat unicast and muticast as mutually exclusive options? The fall back is to use files. Why setup both?
Thanks, Sundar > > ? > > Maybe Frank might have some preference, what the > suitable approach to follow might be. > > > Thank you very much for comments, > Jan >
