Hi Sundar,
Sundar Yamunachari wrote: > Jan, > > Good writeup. My comments are in-line. Thank you very much for your comments - please see my response in line. Jan > > Jan Damborsky wrote: >> Hi Caimaniacs, >> >> As part of install service redesign project, the following problem >> was identified and captured below along with investigation done and >> proposed high level approach how to address it. >> Please yell with questions/comments :-) >> The outcome of this discussion will be reflected in install service >> functional specification. >> >> Thank you, >> Jan >> >> >> [1] Problem statement >> --------------------- >> Boot AI client from network in deterministic way in heterogeneous >> client environment using DHCP without need for client specific setup. >> >> [1a] Current state >> ------------------ >> In current implementation, if both Sparc as well as x86 AI clients >> are configured to be served by one DHCP server without creating >> per client DHCP configuration, unpredictable behavior can occur. >> x86 client can be provided with Sparc NBP or vice versa based on >> the order of configuration steps accomplished. >> >> [2] Scope of the problem >> ------------------------ >> Only early stage of network boot process which serves for obtaining >> NBP is covered here as this is where x86 and Sparc share the boot >> mechanism and where undeterministic behavior could occur. >> Once NBP is obtained, different subsequent boot mechanisms are used >> by x86 >> and Sparc. >> >> For x86, PXEgrub downloads GRUB menu.lst file containing information >> about what to boot in the next stage. >> >> For Sparc, wanboot-cgi script locates wanboot.conf file containing >> the similar set of information. >> >> [3] Definition of terms >> ----------------------- >> NBP >> - network bootstrap program >> - PXEgrub for x86, wanboot-cgi for Sparc >> >> heterogeneous client environment >> - both Sparc & x86 clients are present > Is it limited to sparc and X86 clients booting and installing > OpenSolaris from network? From AI point of view, yes, since AI is assumed to be used for deploying the systems based on OpenSolaris only. From general point of view, no, mix of Linux & Solaris 10 & Opensolaris & ... is assumed. So maybe the definition should be more specific: heterogeneous client environment - OpenSolaris Sparc & x86 AI clients, S10 clients, Linux clients > What about clients installing Solaris 10 and Linux? They are assumed to be present, but not deployed using AI. >> >> AI environment >> - everything which is necessary to allow AI client to be successfully >> deployed using Automated installer - e.g. >> - DHCP server >> - TFTP server >> - AI server providing AI images, install services, AI manifests >> to AI clients using HTTP protocol >> - ... ? >> >> heterogeneous AI environment >> - parts of AI environment are deployed across >> different platforms - e.g. DHCP server running on Linux >> AI server running on Solaris 10 > Does it include booting and installing Solaris 10 clients? In general, the requirement would be ability to coexist with existing jumpstart technology which will be used for deploying S10 clients. For this particular problem, it would mean to utilize existing DHCP server which is already being used by jumpstart. >> >> per client scope >> - applies to AI clients with client specific setup >> >> general scope >> - applies to AI clients without client specific setup >> >> [4] Requirements >> ---------------- >> * AI network boot process has to be deterministic >> * AI network boot process has to work in heterogeneous environment >> without need for client specific setup >> * AI boot process can be configured in heterogeneous AI environment >> - modification of shared pieces (existing DHCP server in this case) >> will be supported and will be as less intrusive as possible >> >> [5] Supported configurations >> ---------------------------- >> * local/remote Sun DHCP server deployed on OpenSolaris & Solaris 10 >> * local/remote ISC DHCP server deployed on OpenSolaris, Solaris 10, >> Linux >> >> [6] Feasibility study >> --------------------- >> The purpose of technical feasibility study is to do initial research >> if technologies to meet the functional requirements exist. >> >> [6.1] Constraints >> ----------------- >> Constraints are determined by the existing technologies AI has to >> plug into. >> >> client side: >> * PXE boot for x86 and early stage of DHCP net boot for Sparc. >> >> server side: >> * DHCP server >> >> [6.2] AI client identification >> ------------------------------ >> In order to provide client with correct NBP, client has to identify >> itself >> to the DHCP server in some way. For the time being, following >> information >> are passed as part of DHCPDISCOVER message which initiates DHCP >> handshake: >> >> x86 PXE client (see [1] for more details): >> * MAC address >> * UUID >> * system architecture (DCHP option 93 - e.g. 0 for x86) >> * class identifier (DHCP option 60 string: >> "PXEClient:Arch:xxxxx:UNDI:yyyzzz, >> "PXEClient:Arch:00000:UNDI:002001" is the only known to be implemented >> for the time being) >> * ... >> >> Sparc: >> * MAC address >> * class identifier (DHCP option 60 string: "SUNW.*", e.g. >> "SUNW.Sun-Fire-v210") >> >> Based on this observation, it seem that there is a way to meet >> the functional requirements taking existing constraints into account: >> >> * per-client scope >> identify client on DHCP server by MAC address >> >> * general scope >> distinguish between x86 & Sparc client architecture by >> inspecting client class identifier string >> >> [7] Proposed high level solution >> -------------------------------- >> Set up DHCP server, so that NBP correctly matching client platform >> will be selected by inspecting client class identifier provided by >> particular AI client. > Is the proposed solution is only for the DHCP server setup by the > installadm tools? Yes, assuming that installadm tools should be common user interface to administer/manipulate AI. > i.e., The DHCP server is running on the install server. remote DHCP configuration is to be supported as well - it is assumed appropriate UI should be provided by installadm This would map to the requirement for installadm redesign project mentioned in section [9]. > The platform specific identifiers are also used by the clients to > install Solaris 10 and older Solaris. If the same DHCP server handles > OpenSolaris clients and Solaris 10 clients, then Solaris 10 clients > might get the OpenSolaris installer boot programs if the per client > DHCP settings were not done for Solaris 10 clients. Is this mechanism supported in existing jumpstart technology ? I mean can be jumpstart clients deployed without client specific setup ? From investigation done so far it seems this feature doesn't exist in jumpstart and is being introduced by AI. If this is being utilized by jumpstart, the collision still might be avoided, if NBPs are common for <=S10 and Opensolaris or can be consolidated. non-Solaris systems seem to be more challenging cases, as we don't have any control over how non-Solaris installers currently configure DHCP servers and how it will change in future. > My other question is " if the client platform identifiers are already > setup in the DHCP server, how will the solution work?" I can think about general set of rules we might apply when trying to plugin into existing infrastructure: * be conservative in what you do and be tolerant in what you accept which might map to * if client platform identifiers are not setup, create them and add our configuration stuff there making sure that the set of rules created have the lowest priority in the existing configuration. * if client platform identifiers are already setup, add our configuration stuff if it doesn't create collision * if client platform identifiers are already setup, but are not compliant with our configuration stuff, report collision and give up. Declare the environment as the one not compliant with 'global scope' - 'per-client scope' could be only deployed in such environments. I am not sure if this answers your question - I agree there are interesting areas to be explored - the question is how deeply we should go with the investigation during this phase. > > Thanks, > Sundar >> >> [8] Deliverables >> ---------------- >> * define DHCP server configuration parameters for supported DHCP >> server implementations for per-client scope and general scope >> (e.g. format of client class identifier macros for SUN DHCP server >> and how they will plug into whole DHCP server configuration) >> >> [9] Related problems/interdependencies >> -------------------------------------- >> * installadm redesign >> - mechanism/API for obtaining valid up-to-date list of client >> class identifiers for Sparc platform >> - mechanism for local/remote update of supported DHCP server >> implementations >> >> * following stages of boot and process of establishing working AI >> client install environment >> >> [10] Related documentation >> -------------------------- >> [1] Preboot Execution Environment Specification v2.1 >> http://download.intel.com/design/archives/wfm/downloads/pxespec.pdf >> >> [2] PXE Wiki >> http://en.wikipedia.org/wiki/Preboot_Execution_Environment >> >> [3] Setting up PXE netboot for x86 clients >> http://www.riddleware.com/solx86/PXE/pxe-netboot.html >> >> [4] Supported AI scenarios and use cases >> http://www.opensolaris.org/os/project/caiman/auto_install/ai_svs_redesign_scenarios.txt >> >> >> >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >
