Ticket 7645

Summary: sacctmgr list where field inherited
Product: Slurm Reporter: Daniel Grimwood <daniel.grimwood>
Component: DocumentationAssignee: Albert Gil <albert.gil>
Status: RESOLVED INFOGIVEN QA Contact:
Severity: 4 - Minor Issue    
Priority: ---    
Version: 18.08.6   
Hardware: Linux   
OS: Linux   
Site: Pawsey Alineos Sites: ---
Atos/Eviden Sites: --- Confidential Site: ---
Coreweave sites: --- Cray Sites: ---
DS9 clusters: --- HPCnow Sites: ---
HPE Sites: --- IBM Sites: ---
NOAA SIte: --- OCF Sites: ---
Recursion Pharma Sites: --- SFW Sites: ---
SNIC sites: --- Linux Distro: ---
Machine Name: CLE Version:
Version Fixed: Target Release: ---
DevPrio: --- Emory-Cloud Sites: ---

Description Daniel Grimwood 2019-08-28 00:24:05 MDT
Hi,

I want to differentiate whether a QOS has been set or inherited, when both values might be the same.

sacctmgr -Q -i modify account set qos=normal where account=$account cluster=$CLUSTER
sacctmgr -Q -i modify user set qos="" where user=A account=$account cluster=$CLUSTER
sacctmgr -Q -i modify user set qos=normal where user=B account=$account cluster=$CLUSTER

is there a search term XXXX for
sacctmgr list assoc where qos=XXXX account=$account cluster=$CLUSTER
that will differentiate between user A and user B?   XXXX=normal and XXXX="" will show both users.

Thanks,
Daniel.
Comment 1 Albert Gil 2019-09-12 13:31:35 MDT
Hi Daniel,

For some reason I missed your question.
Sorry for the late response, my fault.

The good news is that I think that I've a good solution for your question:

> I want to differentiate whether a QOS has been set or inherited, when both
> values might be the same.
> 
> sacctmgr -Q -i modify account set qos=normal where account=$account
> cluster=$CLUSTER
> sacctmgr -Q -i modify user set qos="" where user=A account=$account
> cluster=$CLUSTER
> sacctmgr -Q -i modify user set qos=normal where user=B account=$account
> cluster=$CLUSTER
> 
> is there a search term XXXX for
> sacctmgr list assoc where qos=XXXX account=$account cluster=$CLUSTER
> that will differentiate between user A and user B?   XXXX=normal and XXXX=""
> will show both users.

The way to do it is not exactly a search term to be used in the "where" part of the command, but sacctmgr do have a couple of flags to hide the parent/inherited information:

WOPInfo
  Display information without parent information (i.e. parent id, and parent account name). This option also implicitly sets the WOPLimits option.

WOPLimits
  Display information without hierarchical parent limits (i.e. will only display limits where they are set instead of propagating them from the parent).

So, in your case WOPLimits should do what you are looking for.
As an example I've created a simple scenario where Bob doesn't have an explicit QOS associated, but just inherited, but Sue does:

Without the flag:

$ sacctmgr show assoc tree account=externals format=account,user,qos
             Account       User                  QOS 
-------------------- ---------- -------------------- 
externals                                        low 
 externals                  bob                  low 
 externals                  sue                  low 

With the flag:

$ sacctmgr show assoc tree account=externals WOPLimits format=account,user,qos
             Account       User                  QOS 
-------------------- ---------- -------------------- 
externals                                        low 
 externals                  bob                      
 externals                  sue                  low 

Does it solve your problem?

Also note that WOPLimits works for any limit, but for QOS we also have a specific flag for extra information:

WithRawQOSLevel
  Display QosLevel in an unevaluated raw format, consisting of a comma separated list of QOS names prepended with '' (nothing), '+' or '-' for the association. QOS names without +/- prepended were assigned (ie, sacctmgr modify ... set QosLevel=qos_name) for the entity listed or on one of its parents in the hierarchy. QOS names with +/- prepended indicate the QOS was added/filtered (ie, sacctmgr modify ... set QosLevel=[+-]qos_name) for the entity listed or on one of its parents in the hierarchy. Including WOPLimits will show exactly where each QOS was assigned, added or filtered in the hierarchy.
Comment 2 Albert Gil 2019-09-12 13:38:34 MDT
By the way, we strongly recommend you to upgrade to the last 18.08 (currently 18.08.8), because the specific 18.08.6 that you are using has a known regression bug related to "sacct -j" that you most probably will hit at some point (bug 6697).
We released 18.08.7 quite shortly after 18.08.6 mainly because of it.

Hope that helps,
Albert
Comment 3 Daniel Grimwood 2019-09-12 20:22:21 MDT
Thanks Albert, yes that does what I want.

What I am fully after is this
sacctmgr -p show assoc WOPLimits format=cluster,account,user,qos | awk -F'|' '$4 != ""'
and then from that it's trivial to see whether the QOS override was done at account or user level.

Is it possible with the "where" option to negate a search, to show all associations that don't match the clause?  In particular to do the equivalent of the above line to show only those entries without an empty qos.  Something like where qos!="".

With regards,
Daniel.
Comment 4 Albert Gil 2019-09-13 10:11:06 MDT
Hi Daniel,

> Thanks Albert, yes that does what I want.
> 
> What I am fully after is this
> sacctmgr -p show assoc WOPLimits format=cluster,account,user,qos | awk -F'|'
> '$4 != ""'
> and then from that it's trivial to see whether the QOS override was done at
> account or user level.

Good.

> Is it possible with the "where" option to negate a search, to show all
> associations that don't match the clause?  In particular to do the
> equivalent of the above line to show only those entries without an empty
> qos.  Something like where qos!="".

Unfortunately, right now this is not possible.
We can quicly check it in the parse_option_end() function of sacctmgr:

https://github.com/SchedMD/slurm/blob/842f2ad586aea59ac55ae850ec8f1a52cade5a32/src/sacctmgr/common.c#L81

As you can see sacctmgr only expects "option", "option=value", "option+=value" or "option-=value" formats.
And, although that function can be easily extended, we would also need extra code to communicate the "!=" meaning to the database and to handle corner cases as the !="" (null value) that you would like.
If you are interested in that new feature we can create a request for enhancement bug and discuss it there?

I'm closing the issue as infogiven as it seems that you managed to get waht you wanted with extra awk commands, but please feel free to reopen it if you have further questions or comments.

Thanks,
Albert