Changeset 4450 for trunk/Ohana/src/opihi/doc/pcontrol.txt

Timestamp:

Jul 4, 2005, 5:35:47 PM (21 years ago)

Author:

eugene

Message:

substantial dev work on scheduler/pcontrol/pclient

File:

• trunk/Ohana/src/opihi/doc/pcontrol.txt (modified) (3 diffs)

trunk/Ohana/src/opihi/doc/pcontrol.txt

@@ -80 +80 @@
 can set the CheckTask function to this hook (& unset it).
 
-
 ---
 
@@ -116 +115 @@
  status -queues
 
+pcontrol may be given a timeout for each job.  pcontrol will monitor a
+job and kill/crash it if the timeout expires.  the timeout only
+governs how long it is allowed to execute, not how long it can sit in
+the queue.  (the scheduler / operator should decide if a job has been
+on pcontrol for too long -- this probably means there are no
+appropriate machines ).
+
+pcontrol currently does not distinguish between multiple instances of
+a single host.  all have the same name.  if you want to bring down a
+host, you need to issue N host -down commands.  perhaps this is
+silly.  a simple alternative would be for the host [-on -off -start
+-stop] commands to apply to all defined entries which match the
+hostname.  In this case, a command like 'host foo -off' would find and
+halt all connections to the machine 'foo', while 'host foo -on' would
+restart them all (or rather, given the functionality of pcontrol,
+would allow pcontrol to attempt to bring them on).
+
+It is not clear why a user should be able to execute 'start' (down ->
+idle) or 'stop' (idle -> down).  The transition down -> idle is
+automatically performed by pcontrol for any machines which are
+currently down, while the transition idle -> down is immediately
+followed by an attempt by pcontrol to move the host from down -> idle.
+
+does it makes sense to kill all jobs on a host?  this would only have
+the effect of clearing the host for a moment until pcontrol decided to
+start another job on that host.  the desired effect is gained putting
+the host to 'off'.
  
+currently the command 'host (hostname)' puts the host in 'down'
+state.  pcontrol then immediately tries to connect to the host, moving
+it to 'idle' state (and then 'busy' if any jobs are available).  it
+might be useful to be able to add a host in 'off' state as a starting
+point.  
+
+it is not obvious that the user should be able to run 'CheckHost',
+unless this gets expanded to return state information on the host.
+
 ---
 
@@ -137 +172 @@
 PENDING -> BUSY    : StartJob
 PENDING -> DEL     : DelJob
-BUSY    -> EXIT    : CheckJob
-BUSY    -> CRASH   : CheckJob | KillJob
+BUSY    -> DONE    : CheckBusyJob | KillJob
+DONE    -> EXIT    : CheckDoneJob
+DONE    -> CRASH   : CheckDoneJob
 BUSY    -> PENDING : CheckJob | CheckHost
 EXIT    -> DEL     : DelJob