Hi Jan, On Tue, 3 Mar 2009, jan damborsky wrote:
> 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> Should the install_service_address be in the form of <ip address>:<port> instead in order to be consistent with the mDNS results? > 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. I think this approach seems okay to me for now. I know I was advocating the use of the file based mechanism in favor of DNS entirely last week but the more I think about it, it's more of a kludge that should be religated to being a fallback mechanism only. And, a standard naming service like mDNS or unicast DNS be used for storing the <webserver ip>:<port> pair eventually (like we currently do with mDNS). Alok
