|Date and Author(s)|
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.