svn merge -r9565:9590 https://eris.llnl.gov/svn/slurm/branches/slurm-1.1

NEWS

@@ -36,7 +36,7 @@ documents those changes that are of interest to users and admins.
  -- Moved task layout to slurmctld instead of srun.  Job step create returns
     step_layout structure with hostnames and addresses that corrisponds 
     to those nodes. 
- -- changed api slurm_lookup_allocation params, 
+ -- Changed api slurm_lookup_allocation params, 
     resource_allocation_response_msg_t changed to job_alloc_info_response_msg_t
     this structure is being renamed so contents are the same.
  -- alter resource_allocation_response_msg_t see slurm.h.in

doc/html/moab.shtml

@@ -6,8 +6,8 @@
 beyond the scope of any documents we could supply with SLURM.  
 The best resource for Moab configuration information is the 
 online documents at Cluster Resources Inc.: 
-<a href="http://www.clusterresources.com/pages/resources/documentation/grid/admin.php">
-http://www.clusterresources.com/pages/resources/documentation/grid/admin.php</a>.
+<a href="http://www.clusterresources.com/products/mwm/docs/slurmintegration.shtml">
+http://www.clusterresources.com/products/mwm/docs/slurmintegration.shtml</a>.
 
 <h2>Configuration</h2>
 <p>First, download the Moab scheduler kit from their web site
@@ -28,21 +28,17 @@ with the <i>sched/wiki</i> plugin (both would try to schedule the
 individual processors within a node).</p>
 
 <p>SLURM's wiki configuration is stored in a file 
-specific to the wiki-plugin. This file should be protected 
-from reading by users. It only needs to be readable by 
-<i>SlurmUser</i> (as configured in <i>slurm.conf</i>) and 
-only needs to exist on computers where the <i>slurmctld</i>
-daemon executes.</p>
+specific to the wiki-plugin named <i>wiki.conf</i>. 
+This file should be protected from reading by users. 
+It only needs to be readable by <i>SlurmUser</i> (as configured 
+in <i>slurm.conf</i>) and only needs to exist on computers 
+where the <i>slurmctld</i> daemon executes.
+More information about wiki.conf is available in 
+a man page distributed with SLURM.</p>
 
-<p>The currently supported keywords include:<br>
-<dt><i>AuthKey</i>
-<dd>an encryption key for communctions between 
-SLURM and Maui or Moab
-<dt><i>JobPriority</i>
-<dd>controls execution of newly arriving jobs in SLURM
-</dt></p>
+<p>The currently supported wiki.conf keywords include:</p>
 
-<p><i>AuthKey</i> is a DES based encryption key used to sign 
+<p><b>AuthKey</b> is a DES based encryption key used to sign 
 communctions between SLURM and Maui or Moab. 
 This use of this key is essential to insure that a user 
 not build his own program to cancel other user's jobs in 
@@ -54,8 +50,24 @@ configure line) or Moab (<i>KEY</i> parameter in the
 Note that SLURM's wiki plugin does not include a mechanism 
 to submit new jobs, so even without this key nobody could 
 run jobs as another user.</p>
- 
-<p><i>JobPriority</i> controls the scheduling of newly arriving 
+
+<p><b>EPort</b> is an event notification port in Moab. 
+When a job is submitted to or terminates in SLURM, 
+Moab is sent a message on this port to begin an attempt
+to schedule the computer.
+This numeric value should match <i>EPORT</i> configured 
+in the <i>moab.cnf</i> file.</p>
+
+<p><b>JobAggregationTime</b> is used to avoid notifying Moab 
+of large numbers of events occuring about the same time.
+If an event occurs within this number of seconds since Moab was
+last notified of an event, another notification is not sent.
+This should be an integer number of seconds.
+The default value is 10 seconds.
+The value should match <i>JOBAGGREGATIONTIME</i> configured 
+in the <i>moab.cnf</i> file.</p>
+
+<p><b>JobPriority</b> controls the scheduling of newly arriving 
 jobs in SLURM. 
 SLURM can either place all newly arriving jobs in a HELD state 
 (priority = 0) and let Moab decide when and where to run the jobs 
@@ -74,24 +86,31 @@ AuthKey=1234
 #
 # Have Moab control job scheduling
 JobPriority=hold
+#
+# Moab event notification port, matches EPORT in moab.cfg
+EPort=15017
+#
+# Moab event notifcation throttle, matches JOBAGGREGATIONTIME
+# in moab.cfg (integer value in seconds)
+JobAggregationTime=15
 </pre>
 </p>
 
 <h3>Moab Configuration</h3>
 
 <p>Moab has support for SLURM's WIKI interface by default.
-Specify this interface in the <i>moab.cfg</i> file as follows:
+Specify this interface in the <i>moab.cfg</i> file as follows:</p>
 <pre>
 RMCFG[slurm]         TYPE=wiki:slurm AUTHTYPE=CHECKSUM
 </pre>
-In <i>moab-private.cfg</i> specify the private key as follows:
+<p>In <i>moab-private.cfg</i> specify the private key as follows:</p>
 <pre>
 KEY=1234
 </pre>
-Insure that this file is protected from viewing by users. </p>
+<p>Insure that this file is protected from viewing by users. </p>
 
 <p class="footer"><a href="#top">top</a></p>
 
-<p style="text-align:center;">Last modified 24 August 2006</p>
+<p style="text-align:center;">Last modified 29 September 2006</p>
 
 <!--#include virtual="footer.txt"-->

doc/html/quickstart_admin.shtml

@@ -553,8 +553,8 @@ adev0: scontrol shutdown
 <h2>Testing</h2>
 <p>An extensive test suite is available within the SLURM distribution 
 in <i>testsuite/expect</i>. 
-There are about 150 tests which will execute on the order of 1000 jobs 
-and 2000 job steps. 
+There are about 250 tests which will execute on the order of 2000 jobs 
+and 4000 job steps. 
 Depending upon your system configuration and performance, this test 
 suite will take roughly 40 minutes to complete.
 The file <i>testsuite/expect/globals</i> contains default paths and
@@ -568,19 +568,19 @@ or the full test suite may be executed with the single command
 See <i>testsuite/expect/README</i> for more information.</p>
 
 <h2>Upgrades</h2>
-<p>When upgrading to a new major or minor release of SLURM (e.g. 0.3.x to 0.4.x) 
+<p>When upgrading to a new major or minor release of SLURM (e.g. 1.1.x to 1.2.x) 
 all running and pending jobs will be purged due to changes in state save 
 information. It is possible to develop software to translate state information 
 between versions, but we do not normally expect to do so.
-When upgrading to a new micro release of SLURM (e.g. 0.3.1 to 0.3.2) all
+When upgrading to a new micro release of SLURM (e.g. 1.2.1 to 1.2.2) all
 running and pending jobs will be preserved. Just install a new version of
 SLURM and restart the daemons.
 An exception to this is that jobs may be lost when installing new pre-release 
-versions (e.g. 0.4.0-pre1 to 0.4.0-pre2). We'll try to note these cases 
+versions (e.g. 1.3.0-pre1 to 1.3.0-pre2). We'll try to note these cases 
 in the NEWS file.
 
 </pre> <p class="footer"><a href="#top">top</a></p>
 
-<p style="text-align:center;">Last modified 11 April 2006</p>
+<p style="text-align:center;">Last modified 29 September 2006</p>
 
 <!--#include virtual="footer.txt"-->

doc/html/slurm.shtml

@@ -40,6 +40,7 @@ nodes, each having four Itanium2 processors</li>
 <li><a href="http://www.llnl.gov/asci/platforms/purple/">ASC Purple</a> an IBM SP/AIX 
 cluster with 1500 nodes, each having eight Power5 processors</li>
 </ul>
+There are about 150 downloads of SLURM per month from LLNL's FTP server alone.
 As of September 2006, SLURM has been downloaded over 3500 times to over 500 
 distinct sites in 38 countries. 
 SLURM is also distributed and supported by <a href="http://www.hp.com">