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.
>
>
