On 03/04/09 17:57, Ethan Quach wrote: > > > 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> >> >> 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. > > Jan, > > This approach seems okay for the short term, or at least until > we get a conversation going with the boot team about this.
Ethan, thank you very much for looking at this ! Jan
