IZ2399: Add a qprobe command.

[sgaure]

[Imported from gridengine issuezilla ​http://gridengine.sunsource.net/issues/show_bug.cgi?id=2399]

        Issue #:      2399             Platform:     All           Reporter: sgaure (sgaure)
       Component:     gridengine          OS:        All
     Subcomponent:    scheduling       Version:      6.1u2            CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    ENHANCEMENT
                                   Target milestone: ---
      Assigned to:    andreas (andreas)
      QA Contact:     andreas
          URL:
       * Summary:     Add a qprobe command.
   Status whiteboard:
      Attachments:

     Issue 2399 blocks:
   Votes for issue 2399:


   Opened: Fri Oct 12 17:17:00 -0700 2007 
------------------------


On our cluster we accept jobs from the cern-grid.  The middleware there expects
to be able to figure out how many slots are available for its use.  We have
wrapped qstat -xml for this and other purposes because our policies are quite
complicated, so a qstat -g c doesn't tell the full picture.  It is, I think, a
general problem to figure out how many slots are available.  But it has a not
so difficult solution.

It would be nice to have something like a qprobe command, which could tell me
what would happen if I submit now.

# qprobe -l whatever -P smth -t 60-200 -now y
job would start on 73 slots
or, more ambitious
# qprobe -l whatever -P smth -t 60-200 -now n -R y
00:00:00: 73 slots
00:35:20: 85 slots
02:20:43: 120 slots
12:23:50: 200 slots

or even report the full list of queue instances the job would run in.

A simple version of qprobe could be implemented with a "dryrunjob" possibility
in the scheduler, i.e. a job which isn't debited (or change the scheduler state
in a material way), and the order is sent back to qprobe rather than used to
start the job.

This information is very hard to get at otherwise, because information about
reservations are not easily available from the scheduler, and extracting all
this from a full qstat (and qconf and rqs and stuff) requires duplicating most
of the scheduling functionality.

The timing can of course not be guaranteed, but it would at least provide a
snapshot of what's going on right now.

   ------- Additional comments from sgaure Fri Oct 12 17:18:27 -0700 2007 -------
changed from 5.3 to 6.1