[prev in list] [next in list] [prev in thread] [next in thread] 

List:       grid-engine-dev
Subject:    Re: [GE dev] Overwrite sge_request
From:       Nick Maclaren <nmm1 () cus ! cam ! ac ! uk>
Date:       2004-10-21 20:34:20
Message-ID: E1CKjdc-0004wy-Fu () virgo ! cus ! cam ! ac ! uk
[Download RAW message or body]

> Sure, the problems of being able to specify default command line options in
> various places always can cause problems since the user doens't know what
> e.g. his admin specified as default. However talking about the "-q" switch
> the feedback and comments from our users has shown that concatenate the
> queue list is not what people ususally expect. So I think we should address
> the "-q" issue in patch.

Yes.  I was referring to the generic one of a later setting overriding
an earlier.  This isn't too bad with qsub, as the options are largely
orthogonal, but it is a real disaster with most compilers.  Even with
qsub, however, SOME combinations interact in weird ways.

> As an admin you certainly need to be able to have closer control about
> resource request sometimes - the submit wrapper option is certainly doable
> but still can be bypassed by users (accidentially or intentionally). I think
> what we need is a concept (preferably implemented in the sometimes on this
> list mentioned job class concept) how an admin is able to specify in qmaster
> rules how resource requests look like.

Yes.  Actually, it is possible to make it secure - I did it for the
X clients at one stage to block out idiots who used 'xhost +' - but it
is a pain in the, er, neck.

Yes, I agree that a generic concept is needed, and the one that I would
favour is like the Loadleveler SUBMIT_FILTER.  This is a script/program
that is passed the script the user specifies and outputs the script to
be used (modified and rejected as appropriate).  And that is what I was
looking into doing.

> Can you give some examples how the operational model in your cluster looks
> like - this information can be useful for getting ideas what Grid Engine
> would need to offer to fullfill your needs?

Please see:

    http://www.hpcf.cam.ac.uk/prog_franklin_qsub.html

If you would like to see the filtering script, or even the whole
configuration, please ask.  It takes the draconian viewpoint of saying
that we have a fixed number of types of queue - pick one.  It allows
any options that don't get in the way of that, and diagnoses all that
do (or ones that won't work).  By default, pretty well every scheduler
will accept jobs that will never run.

> (of course there's always the low level approach - enabling the customer to
> create his own shared libarary which his linked against qmaster and which
> allows the admin to create a "resource request checking and adjusting code"
> - however I think this is absolutely not the way how a queueing system
> should provide interfaces to its users today).

Yes.  Scripting is far better, especially for something like this, which
is not resource critical.  The actions of submitting and running a job
fire up so many processes that one more isn't an issue.  And you can
use your favourite scripting language (or ever C, if you are really
determined).

> >    1) Finding out how to add a queue option, which I have so far
> > found only to be far better hidden than I was expecting.  Any hints
> > of where to hack would be welcome.
> 
> Do you mean finding this in the qsub code?

Yes.  And in the qmon code.  I have found where such options are used,
but not where they are defined.  It is clearly not IN the qsub/qmon
code, but in some shared code.

> >    2) Passing the arguments over and receiving the result.  This is
> > clearly possible, but messy, as the way Gridengine works isn't ideally
> > suited to doing it.
> 
> Passing the arguments over to what?

A suitable munging script.  See above.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679

[prev in list] [next in list] [prev in thread] [next in thread]