[torquedev] Re: [torqueusers] how to disable interactive job submission

Glen Beane glen.beane at gmail.com
Wed Mar 14 07:02:40 MDT 2007


On 3/13/07, Garrick Staples <garrick at usc.edu> wrote:
> On Tue, Mar 13, 2007 at 09:32:40PM -0600, Garrick Staples alleged:
> > On Tue, Mar 13, 2007 at 10:18:12PM -0400, Glen Beane alleged:
> > > On 3/13/07, Glen Beane <glen.beane at gmail.com> wrote:
> > > >On 3/13/07, Glen Beane <glen.beane at gmail.com> wrote:
> > > >> On 3/13/07, Garrick Staples <garrick at clusterresources.com> wrote:
> > > >> > On Tue, Mar 13, 2007 at 05:13:17PM +0100, Ronny T. Lampert alleged:
> > > >> > > Quite frankly I think - the current situation sucks.
> > > >> > > As there are only 2 types of jobs (batch, interactive), there should
> > > >be
> > > >> > > an attribute for EACH queue, as in:
> > > >> > >
> > > >> > > queue_allowed_types=batch,interactive
> > > >> > >
> > > >> > > Admins can set the allowed types accordingly.
> > > >> > > The submit-filter is way too complicated.
> > > >> >
> > > >> > Since people keep asking for it, I'll stop vetoing the idea if someone
> > > >> > writes the patch.
> > > >> >
> > > >> > But I still think it is a bad idea.
> > > >>
> > > >> If we do this, instead of a single queue attribute
> > > >> (queue_allowed_types=batch,interactive) we should have two:
> > > >> allow_batch, and allow_interactive.   Both would be true by default.
> > > >> To disable interactive jobs for a queue: qmgr -c "s q queue_name
> > > >> allow_interactive = false"
> > > >>
> > > >> This wouldn't be hard to do,  and even though Garrick will hate me I
> > > >> think I might do this  right now :)
> > > >
> > > >I have this working.  A little more testing and it will be checked into
> > > >trunk.
> > >
> > > checked into trunk
> > > please test
> >
> > I'm probably a little late in saying this, since you've already done the
> > work, but you might as well go with the original idea.
> >
> > People will start asking for all kinds of allowable restrictions like
> > STDIN versus batch scripts, rerunnable, dependencies, and all sorts of
> > other rubbish.
> >
> > With a single list attribute, we can easily tack on new diabolical
> > restrictions.
>
> Did I sound derisive enough?
>
> As admins, we care about *what* resources are used.  We care about
> amounts of cputime, walltime, NFS traffic, memory usage, disk usage,
> etc.  We care that the resources are available, reliable, and above all,
> useful.
>
> What we don't care about is *how* the resources are used.  We don't
> care if the job is written in bourne, perl, fortran, C or C#, the color
> of the user's shirt, if the user likes dogs or cats, or whether the job
> is interactive or batch.

What if I want a high priority queue that only services interactive
jobs, but I want to put walltime restrictions on these interactive
jobs so users don't abuse the high priority by submitting interactive
jobs just so they will run faster?  Could be useful for developers
that want interactive time to debug their code


More information about the torquedev mailing list