Jan Damborsky wrote: > 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. okay. > >>> >>> 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. Jumpstart doesn't support directly setting up server for using with out a client specific setup. But it doesn't stop any one setting up such a configuration and use the platform specific macros for different purposes. > > 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. I don't know whether a common NBP can be used. We need to check with the boot team. > > 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: It is good to identify the situations. > > * 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. You outlined a good plan to approach the problem. That is enough for now. Getting all the different customer scenario is difficult.
Thanks, Sundar > >> >> 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 >> >
