Node Build and Configuration Notebook - page 33 of 55

EditDeleteAnnotateNotarize
First PagePrevious PageNext PageLast PageTable of ContentsSearch

Date and Author(s)

Interfaces to "Node Manager"

The Node Manager as described here, relates to a prototype that 
initially kept track of state as well as function.  Then state and 
function were seperated.  The current iteration of the BCWG designs  
(as mentioned by Narayan & Rusty on p.32) encompasses this in general.  
Therefore this information is slightly redundant but is provided to  
help resolve differences. 
 
 
The Node Manager (NodeMgr) is in charge of peforming functions,  
e.g. Reboot, Halt, CyclePower, [Get|Set]Image.  Here "image" can be 
rather amorphous -- SystemImager or Chiba "images" (tags) -- simply 
an identifier that is used to map a node to a configuration. 
 
 
The basis being that one can perform common administrative functions 
via a standard interface.    
 
 
 Information needed: 
  + node identifier   (Node identification information) 
  + image identifier  (Node configuration information, BuildSystem related?) 
 
 
 Information provided: 
  + Administrative function [requests] 
    - request acks 
    - request "return codes" [manually or via EventMgr] 
 
 Events provided: 
  + Node state changes 
  + Node configuration changes 
 
 
 
============ 
 Services needed: 
  + Cluster-wide "atomic" state manipulations (set/get state) 
  	- i.e. play nicely w/ other components like Scheduler 
	- I believe NodeStateMgr will come to play here. 
 
  + Possibly async responses (image build completed) 
  	- I believe EventMgr will come to play here.