I think that's the AllocNode on the Partition?

See here http://slurm.schedmd.com/slurm.conf.html

and http://slurm.schedmd.com/scontrol.html

(search for AllocNode on both)

Cheers
L.

------
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 18 June 2016 at 10:16, Owen LaGarde <[email protected]> wrote:

> Never mind, found it in the bottom of the programmer_guide page.  Yes I
> was being stupid.  "Frontend" to slurm is not at all synonymous with
> "frontend" in the HPC community.  In fact it's the opposite -- a slurm
> "frontend" not only is allocatable, but is allocatable as an arbitrary
> number of nodes under one slurmd instance.
>
> So what's the equivalent, in slurm, of distinguishing between nodes that
> may and nodes that may not pass requests to the controller, all such nodes
> *not* being participants in any resource pool under that controller?
>
> Example:  under PBSPro, I can set a restriction on access to management
> commands by login and/or host and/or domain like this:
>
>     qmgr -c 'set server managers = "{login}@{host|*}.{domain},...'
>
> and can similarly restrict who can talk to the scheduler at all.  We tend
> to use this sort of thing to allow, for example, a set of dedicated login
> nodes in a cluster to submit jobs and query status, while a subset of
> logins on the same nodes can also run administrative PBS subcommands, and a
> third set of external-to-the-cluster hosts is allowed to only query
> status.  What's the most appropriate (slurm-like?) way to do this under
> slurm?
>
> On Fri, Jun 17, 2016 at 5:03 PM, Owen LaGarde <[email protected]> wrote:
>
>> I'm fairly new to slurm, bear with me...I think I'm stupidly missing
>> something obvious...
>>
>> Is --enable-front-end doing something significant *other* than enabling
>> the 'FrontendName=' (slurm.conf) option?  I ask because having "frontend"
>> nodes -- that are allowed to communicate with the scheduler, query status,
>> [possibly] submit tasks or request resources, etc -- is a pretty common
>> practice at the scales where slurm excels.  Or, at least, it is in the HPC
>> arena (yes, this could easily be weird only to me).  I see it's in the
>> configure, but not in the specfile even as a --with or --slurm-with.  Why
>> have frontend support out-of-the-box only for those building with the
>> BlueGene option instead of on-by-default?
>>
>> As a counter-example:  historically we've run PBSPro, LSF, NQS, and
>> "other" resource managers on a number of architectures which by design
>> required frontends -- their "backend" nodes didn't support user logins or
>> interactive environments.  All arch's that didn't require frontends had
>> them anyway;  our customers demanded them as separate, un-allocatable
>> resources for login activities, specifically to insulate the impact of
>> those activities from the compute pool.  So seeing a batch system that can
>> do what slurm does, but doesn't support frontends by default, that makes me
>> think I'm missing something obvious here about slurm frontend support.
>>
>>
>

Reply via email to