Hi Alok,
On 03/03/09 17:45, Alok Aggarwal wrote: > 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? I have looked at how mDNS service is registered and you are right, machine IP address is there, so we will follow the same implementation. In general, both will work (hostname as well as IP address), since name service (DNS) on AI client will take care of resolving the host name. > >> 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). I agree - the fallback mechanism has limitations which are acceptable in the scenario we address with this fix, but might not be acceptable in other scenarios. Thanks for your comments ! Jan
