Currently, Automated installer uses multicast DNS for service discovery. The problem with the existing implementation is that since multicast DNS utilizes multicast IP packets which can deliver information only within local subnet, AI server can only serve AI clients on the same subnet.
It was initially considered to take advantage of unicast DNS to address this limitation. During investigation of possible approaches was discovered that more research is needed and more time has to be dedicated to design. As a less risky solution at this point, fallback mechanism is considered to be used. This means that AI client will be provided with direct location of particular install service (machine address and port number) along with service name. If service discovery using multicast DNS fails, fallback mechanism will be used and machine providing given service will be connected directly. The proposal suggests to take advantage of existing implementation and use the same mechanism for passing location of service which is used for passing install service name. That means new option (e.g. 'install_service_address') will be implemented and added along with existing 'install_service' to either GRUB menu.lst (for x86) or install.conf (for Sparc). examples: * x86 menu.lst file ... kernel$ ... -B install_media=<ai_image_location>,install_service=_install_service_46501, install_service_address=<machine>:<port> * Sparc install.conf file install_service=_install_service_46501 install_service_address=<machine>:<port> Raised concerns: * we need to make sure that GRUB menu.lst is not overloaded It is out of the scope of this fix to address this concern, but the longer term plan is to introduce common configuration file for both x86 and Sparc residing outside of AI image area (so that AI image can be lofi mounted - then it will be read only). Then AI client could process configuration file in the same way for both architectures and use menu.lst only for passing the necessary information (kernel and boot archive location, kernel parameters). Please let me know, if you think it should be modified or different approach should be taken. Thank you very much, Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20090303/93cf4350/attachment.html>
