<br><br><div class="gmail_quote">On Tue, Dec 4, 2012 at 11:59 AM, Ken Nielson <span dir="ltr">&lt;<a href="mailto:knielson@adaptivecomputing.com" target="_blank">knielson@adaptivecomputing.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br><br><div class="gmail_quote">On Tue, Dec 4, 2012 at 11:54 AM, Glen Beane <span dir="ltr">&lt;<a href="mailto:glen.beane@gmail.com" target="_blank">glen.beane@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>On Tue, Dec 4, 2012 at 1:37 PM, David Beer &lt;<a href="mailto:dbeer@adaptivecomputing.com" target="_blank">dbeer@adaptivecomputing.com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; Ken,<br>
&gt;&gt;<br>
&gt;&gt; This could work.  There are lots of things that could work.  My point is<br>
&gt;&gt; that the default behavior doesn&#39;t have any value (except it already exists).<br>
&gt;&gt; I want the users (and myself) to do as little as possible.  I asked the<br>
&gt;&gt; question in a way I hoped would discuss if anyone else is bothered by the<br>
&gt;&gt; default behavior.  Maybe I am the only one that cares that &quot;qstat&quot; generates<br>
&gt;&gt; too much information in a way that I think is unnecessary.<br>
&gt;&gt;<br>
&gt;&gt; Craig<br>
&gt;&gt;<br>
&gt;<br>
&gt; One case for not changing the default is that Moab and Maui both depend on<br>
&gt; completed jobs appearing so that they can harvest appropriate information<br>
&gt; from them. This doesn&#39;t mean we absolutely can&#39;t change it - these could be<br>
&gt; made so that they request appropriately based on TORQUE versions - but it<br>
&gt; does mean that if we did change it then we&#39;d break backwards compatibility<br>
&gt; with older versions of Moab/Maui, which is a significant consideration.<br>
&gt;<br>
<br>
</div></div>But Maui and Moab don&#39;t run the qstat executable.  What if the API<br>
default were to return all jobs, including complete, but we could pass<br>
a flag with the request to the server from qstat so the server knows<br>
if the client wants information for completed jobs. We could add a<br>
qmgr setting to change the default behavior.  qstat would include some<br>
extra information that would specify &quot;give me all jobs&quot;, &quot;give me<br>
everything but complete&quot;, or &quot;give me the server default&quot; (which would<br>
be the default behavior for qstat).  I think most of the API calls<br>
allow passing &quot;extra&quot; information (that may not be used by many of the<br>
calls).  We might be able to use this to convey this information.<br>
<div><div>_______________________________________________<br></div></div></blockquote></div><br></div></div>Glen,<br><br>Hmm. You are right. <br><br>qstat always gets all of the jobs regardless of their state and then formats the output based on the command line switches. Even so, changing default behaviour is almost always problematic. What we fix for one person generally breaks someone else.<span class="HOEnZb"><font color="#888888"><br>

<br></font></span></blockquote><div><br></div><div>Ken,</div><div><br></div><div>I had figured out most of the behavior when looking at the code.  I had a snippet that would ask for all job states except for &quot;C&quot; instead of using the default.  Then I added an option for -c and that would only pass back completed jobs.  I didn&#39;t go into the server code and change how it worked because I figured that would break Moab.</div>
<div><br></div><div>The reason for breaking them out is:</div><div><br></div><div>1) It causes (IMO) unnecessary clutter</div><div>2) If you (well I) want the completed job to be useful, the keep_completed_jobs needs to be at least an hour, but preferably a day</div>
<div>2b) When you start having thousands of jobs per hour going through the system, the number of complete jobs goes up drastically and slows down the qstat commands when few people really care (see #1)</div><div>3) Unless I reachitect our Torque servers, users never have any access to the information to get the exit status from the log files.  Plus that still requires parsing ascii log files which is not efficient (where keeping the exit code in memory is efficient).</div>
<div><br></div><div>I know it is changing default behavior and isn&#39;t something that can be done overnight.  My point was to get others to express opinions of the current functionality and is it really the best to do.  Maybe the change couldn&#39;t be made until 5.0, where you have a chance to break things.  Changing it in qstat means it never breaks the server so you don&#39;t have compatibility issues there.</div>
<div><br></div><div>Thanks,</div><div>Craig</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">Ken<br>
</font></span><br>_______________________________________________<br>
torqueusers mailing list<br>
<a href="mailto:torqueusers@supercluster.org">torqueusers@supercluster.org</a><br>
<a href="http://www.supercluster.org/mailman/listinfo/torqueusers" target="_blank">http://www.supercluster.org/mailman/listinfo/torqueusers</a><br>
<br></blockquote></div><br>