X-Git-Url: http://git.onelab.eu/?a=blobdiff_plain;ds=sidebyside;f=documentation%2Fboot-manager-tech-doc.xml;h=ac05d51d9b7bb264db9775d72ef9b4982231fe21;hb=ee890be3c5b2c0e27411382adb097bee49ae032d;hp=7463d3fe0bf2374e25ae8267ebecba04d329506d;hpb=8412dc83e50649c6b3e2f27579f5a2cd6501a5c6;p=bootmanager.git
diff --git a/documentation/boot-manager-tech-doc.xml b/documentation/boot-manager-tech-doc.xml
index 7463d3f..ac05d51 100644
--- a/documentation/boot-manager-tech-doc.xml
+++ b/documentation/boot-manager-tech-doc.xml
@@ -86,17 +86,13 @@
Components
The entire BootManager system consists of several primary
- components. These consist of:
+ components. These are:
The existing, stardard MA provided calls to allow principals to
- add and manage node records
-
-
-
- New MA API calls, for use by principals, to generate
- node-specific configuration files
+ add and manage node records, and a new call to generate node-specific
+ configuration files
@@ -111,12 +107,12 @@
The intention with the BootManager system is to send the same script
- back for all nodes (consisting of the core BootManager code), in all boot
- states, each time the node starts. Then, the BootManager will run and
- detiremine which operations to perform on the node, based on the current
- boot state. All state based logic for the node boot, install, debug, and
- reconfigure operations are contained in one place; there is no boot state
- specific logic located on the MA servers.
+ to all nodes (consisting of the core BootManager code), each time the node
+ starts. Then, the BootManager will run and detiremine which operations to
+ perform on the node, based on its state of installation. All state based
+ logic for the node boot, install, debug, and reconfigure operations are
+ contained in one place; there is no boot state specific logic located on
+ the MA servers.
- Management Authority Node Fields
+ Management Authority Node Fields
- The following fields MA database fields are directly applicable to
- the BootManager operation, and to the node-related API calls (detailed
+ The following MA database fields are directly applicable to the
+ BootManager operation, and to the node-related API calls (detailed
below).
@@ -167,10 +163,10 @@
'inst'
Install. The boot state cooresponds to a new node that has not
- yet been installed, but record of it does exist. When the boot
- manager starts, and the node is in this state, the user is prompted
- to continue with the installation. The intention here is to prevent
- a non-PlanetLab machine (like a user's desktop machine) from
+ yet been installed, but record of it does exist. When the
+ BootManager starts, and the node is in this state, the user is
+ prompted to continue with the installation. The intention here is to
+ prevent a non-PlanetLab machine (like a user's desktop machine) from
becoming inadvertantly wiped and installed with the PlanetLab node
software. This is the default state for new nodes.
@@ -186,9 +182,9 @@
'boot'
- Boot. This state cooresponds with nodes that have sucessfully
- installed, and can be chain booted to the runtime node
- kernel.
+ Boot to bring a node online. This state cooresponds with nodes
+ that have sucessfully installed, and can be chain booted to the
+ runtime node kernel.
@@ -196,7 +192,8 @@
Debug. Regardless of whether or not a machine has been
installed, this state sets up a node to be debugged by
- administrators.
+ administrators. In debug mode, no node software is running, and the
+ node can be accessed remotely by administrators.
@@ -206,7 +203,7 @@
Existing Management Authority API Calls
These calls, take from the PlanetLab Core Specification and extended
- with additional parameters, are used by Principals to maintain the set of
+ with additional parameters, are used by principals to maintain the set of
nodes managed by a MA. See the Core Specification for more information.
The MA may provide an easy to use interface, such as a web interface, that
calls these directly.
@@ -215,9 +212,9 @@
AddNode( authentication, node_values )
- Add a new node record. node_values contains hostname,
- ipaddress, and the new fields: boot_state. The resultant node_id is
- returned.
+ Add a new node record. node_values contains hostname, ip
+ address and other network settings, and the new fields: boot_state.
+ The resultant node_id is returned.
@@ -277,8 +274,8 @@
The authentication string, depending on method. For the 'hmac'
method, a hash for the call using the HMAC algorithm, made from the
- parameters of the call the key contained on the configuration file.
- For specifics on how this is created, see below.
+ parameters of the call and the key contained on the configuration
+ file. For specifics on how this is created, see below.
@@ -338,7 +335,8 @@
prevent replay attacks. In fact, the current use of SSL negates the
need to create and send hashes across - technically, the key itself
could be sent directly to the MA, assuming the connection is made to
- an HTTPS server with a third party signed SSL certificate.
+ an HTTPS server with a third party signed SSL certificate being
+ verified.
@@ -383,8 +381,8 @@
include_tech, include_support )
Notify someone about an event that happened on the machine,
- and optionally include the site PIs, technical contacts, and
- PlanetLab Support.
+ and optionally include the site Principal Investigators, technical
+ contacts, and PlanetLab Support.
@@ -399,8 +397,8 @@
Generate a configuration file to be used by the BootManager
and the BootCD to configure the network for the node during boot.
This resultant file also contains the node_id and node_key values.
- A new node_key is generated each time. The full contents and
- format of this file is detailed below.
+ A new node_key is generated each time, invalidating old files. The
+ full contents and format of this file is detailed below.
@@ -472,8 +470,6 @@
-
-