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. thanks, -ethan > > Thank you very much, > Jan > > > ------------------------------------------------------------------------ > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
