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

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

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.

[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


Reply via email to