Ticket 5997

Summary:	Exclude User from Partition
Product:	Slurm	Reporter:	Paul Edmon <pedmon>
Component:	Limits	Assignee:	Unassigned Developer <dev-unassigned>
Status:	OPEN ---	QA Contact:
Severity:	5 - Enhancement
Priority:	---	CC:	tim
Version:	17.11.12
Hardware:	Linux
OS:	Linux
Site:	Harvard University	Alineos Sites:	---
Atos/Eviden Sites:	---	Confidential Site:	---
Coreweave sites:	---	Cray Sites:	---
DS9 clusters:	---	HPCnow Sites:	---
HPE Sites:	---	IBM Sites:	---
NOAA SIte:	---	NoveTech Sites:	---
Nvidia HWinf-CS Sites:	---	OCF Sites:	---
Recursion Pharma Sites:	---	SFW Sites:	---
SNIC sites:	---	Tzag Elita Sites:	---
Linux Distro:	---	Machine Name:
CLE Version:		Version Fixed:
Target Release:	---	DevPrio:	---
Emory-Cloud Sites:	---

Description Paul Edmon 2018-11-07 12:03:41 MST

We'd like to add a feature where we can exclude specific users from a partition even if they are part of the unix group that has permission to use the cluster.  This way we don't have to create a completely new unix group to only include those who have access.

Comment 3 Jason Booth 2018-11-07 12:21:45 MST

Hey Paul,

As you mentioned, in this case, the DenyAccounts does not seem to be an option for you. We do have a DenyQos option, although I suspect that your users may also have multiple QOSes and you may just want to outright deny a subset of users regardless of account or QoS. Please let me know if this is not the case. 

DenyQos
Comma separated list of Qos which may not execute jobs in the partition. By default, no QOS are denied access NOTE: If AllowQos is used then DenyQos will not be enforced. Also refer AllowQos.

-Jason

Comment 4 Paul Edmon 2018-11-07 12:26:15 MST

Yes, this is the case.  We do have multiple QoS's for users so DenyQoS 
wouldn't work in our case.

-Paul Edmon-

On 11/7/2018 2:21 PM, bugs@schedmd.com wrote:
>
> *Comment # 3 <https://bugs.schedmd.com/show_bug.cgi?id=5997#c3> on bug 
> 5997 <https://bugs.schedmd.com/show_bug.cgi?id=5997> from Jason Booth 
> <mailto:jbooth@schedmd.com> *
> Hey Paul,
>
> As you mentioned, in this case, the DenyAccounts does not seem to be an option
> for you. We do have a DenyQos option, although I suspect that your users may
> also have multiple QOSes and you may just want to outright deny a subset of
> users regardless of account or QoS. Please let me know if this is not the case.
>
> DenyQos
> Comma separated list of Qos which may not execute jobs in the partition. By
> default, no QOS are denied access NOTE: If AllowQos is used then DenyQos will
> not be enforced. Also refer AllowQos.
>
> -Jason
> ------------------------------------------------------------------------
> You are receiving this mail because:
>
>   * You reported the bug.
>

Comment 6 Jason Booth 2018-11-07 13:32:10 MST

Paul,

 Would you elaborate a bit more on why the account membership would or would not be an option in your case?

Comment 7 Paul Edmon 2018-11-07 13:35:17 MST

Really its more of a convenience issue.  We have a PI who wishes to 
exclude one user from the partition he has but then use the rest of the 
resources on the cluster and still be charged for his runs.  We could 
make a new group for just that partition but then when new users come in 
they won't be automatically add to that group but just to the PI's 
group.  In reality this is just to save us headache on our backend AD 
structure.

-Paul Edmon-

On 11/7/18 3:32 PM, bugs@schedmd.com wrote:
>
> *Comment # 6 <https://bugs.schedmd.com/show_bug.cgi?id=5997#c6> on bug 
> 5997 <https://bugs.schedmd.com/show_bug.cgi?id=5997> from Jason Booth 
> <mailto:jbooth@schedmd.com> *
> Paul,
>
>   Would you elaborate a bit more on why the account membership would or would
> not be an option in your case?
> ------------------------------------------------------------------------
> You are receiving this mail because:
>
>   * You reported the bug.
>