Hi Sundar, Sundar Yamunachari wrote: > 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.
If you agree, then we might use optional '-p port' command line option in order to provide user with a way to explicitly specify which port should be picked up by the service. If not specified, port number for unicast DNS would be determined by utilizing the same algorithm which is used for for multicast DNS. In order to provide consistent user experience, we might allow this to be used for both multicast as well as unicast DNS. >>>> >>>> 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. Will we need to allow user to use both in some cases, or will it be always mutually exclusive ? >>>> >>>> * 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. Agreed. >>>> >>>> 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. I think that we should provide user with consistent experienc. If we allow to explicitly specify port number for unicast DNS, I think it might be expected that the same is possible for multicast as well. And if it is supported to let AI decide automatically about port number for multicast DNS, it might be desirable to support the same for unicast. >>>> >>>> >>>> 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? I was thinking that multicast DNS might provide one more level of fallback mechanism for unicast DNS. I am not sure if this is something user would like to take advantage of or expect to work. If this might be source of confusion then I agree we should treat unicast and multicast as mutually exclusive - at least for default behavior. We could initially implement this as mutually exclusive which is more deterministic and if we see that people will ask for modification, we could enhance it. Thank you, Jan
