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? > > * 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? > * 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. Dave
