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 * 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' * 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 Compatiblity: ------------ New installadm tools would be compatible with old client: * if uDNS specified, service would be also registered using mDNS and old AI client would just ignore uDNS and use mDNS Old installadm tools would be compatible with new client, since new client would be backward compatible with previous API. Thank you, Jan On 02/16/09 21:56, Sundar Yamunachari wrote: > Hi, > > I sent out a list of tasks to be considered for the AI spring > release in December 2009. Based on the feedback and priority of the > tasks, we are planning to do the top six or seven tasks for the next > release. The design document for the AI spring release is at > http://www.opensolaris.org/os/project/caiman/auto_install/Design_doc_delta_for_AI_Spring_2009.pdf. > > This can be also accessed from the Caiman documentation page at > http://www.opensolaris.org/os/project/caiman/auto_install/Documentation. > Please provide your feedback. The focus of next release is usability > and quality. Ethan Quach contributed most of changes we are planning > for the AI spring release. > > Thanks, > Sundar > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
