From ee890be3c5b2c0e27411382adb097bee49ae032d Mon Sep 17 00:00:00 2001 From: Aaron Klingaman Date: Fri, 24 Mar 2006 19:22:23 +0000 Subject: [PATCH] more changes to make it fit in new MA terminology --- documentation/boot-manager-tech-doc.xml | 70 ++++++++++++------------- 1 file changed, 33 insertions(+), 37 deletions(-) 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.
@@ -129,10 +125,10 @@
- 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 @@ - -
-- 2.43.0