Ticket 16485 - requesting user information, results (associations) doesn't match 'sacctmgr'
Summary: requesting user information, results (associations) doesn't match 'sacctmgr'
Status: RESOLVED INFOGIVEN
Alias: None
Product: Slurm
Classification: Unclassified
Component: slurmrestd (show other tickets)
Version: 22.05.7
Hardware: Linux Linux
: 4 - Minor Issue
Assignee: Marshall Garey
QA Contact:
URL:
Depends on:
Blocks:
 
Reported: 2023-04-09 08:01 MDT by Greg Wickham
Modified: 2023-05-02 16:37 MDT (History)
0 users

See Also:
Site: KAUST
Slinky Site: ---
Alineos Sites: ---
Atos/Eviden Sites: ---
Confidential Site: ---
Coreweave sites: ---
Cray Sites: ---
DS9 clusters: ---
Google sites: ---
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: ---

Attachments
JSON dump of results from REST query (1.76 KB, text/plain)
2023-04-09 08:01 MDT, Greg Wickham 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this ticket.
Description Greg Wickham 2023-04-09 08:01:31 MDT 
Created attachment 29766 [details]
JSON dump of results from REST query

Running a query with "sacctmgr"

$ sacctmgr show assoc user=alamaom format=user,account
      User    Account 
---------- ---------- 
   alamaom pi-caninim 

Comparing this to the output of:

   http://slurm:6820/slurmdb/v0.0.37/user/alamaom

doesn't match. (See attachment with full results of REST GET)

Is this the correct REST query to fetch the associations of a user?

If so, is it expected to match the output of an equivalent "sacctmgr"?

   -Greg
Comment 2 Marshall Garey 2023-04-10 10:12:32 MDT 
You're using the user endpoint:

>    http://slurm:6820/slurmdb/v0.0.37/user/alamaom

But calling sacctmgr show assoc (not show user):

> $ sacctmgr show assoc user=alamaom format=user,account

If you want the association data, then use the association[s] endpoint:

https://slurm.schedmd.com/rest_api.html#slurmdbV0038GetAssociation
https://slurm.schedmd.com/rest_api.html#slurmdbV0038GetAssociations

Does this answer your question?
Comment 3 Greg Wickham 2023-04-10 11:21:34 MDT 
Hi Marshall,

Ah!

Ok.

Thanks.

The user endpoint returns associations too thou, which is a bit confusing as it returns both active and deleted associations.

   -Greg
Comment 5 Greg Wickham 2023-04-11 01:54:53 MDT 
Confirming the /associations endpoint works great - even includes "is_default" which is quite handy.
Comment 6 Marshall Garey 2023-04-11 10:26:33 MDT 
Thanks for letting me know that the associations endpoint works great for you.

(In reply to Greg Wickham from comment #3)
> The user endpoint returns associations too thou, which is a bit confusing as
> it returns both active and deleted associations.

I only see active associations. When I delete an association (for example, a user from one of their accounts), and run the user[s] endpoint, I don't see that association for that user anymore.

What deleted associations do you see with the users endpoint?
Comment 7 Greg Wickham 2023-04-13 01:58:34 MDT 
Hi Marshall,

In the initial example doing a "show assoc" with sacctmgr showed a single association however using the user REST endpoint found deleted associations.

(See the attached file).

   -greg
Comment 8 Marshall Garey 2023-05-02 16:37:21 MDT 
Hi Greg,

Sorry for the delayed response.

(In reply to Greg Wickham from comment #7)
> Hi Marshall,
> 
> In the initial example doing a "show assoc" with sacctmgr showed a single
> association however using the user REST endpoint found deleted associations.

The reason I could not reproduce this is that I was deleting an association without running jobs in that association, thus removing it from the database instead of just marking it as deleted.

https://slurm.schedmd.com/sacctmgr.html#OPT_WithDeleted_1

With that in mind, I reproduced the user endpoint showing deleted associations.

Showing deleted associations is actually the default for dbv37, but was changed for dbv38, alongside adding the "with_deleted" query parameter. See these entries in the NEWS file:

 -- openapi/dbv0.0.38 - set with_deleted to false by default for /user[s].
 -- openapi/dbv0.0.38 - add with_deleted input parameter to GET /user[s].
 -- openapi/dbv0.0.38 - add deleted flag to /user[s] output.
 -- openapi/dbv0.0.38 - set with_deleted to false by default for GET /qos.
 -- openapi/dbv0.0.38 - add with_deleted input to GET /qos.
 -- openapi/dbv0.0.38 - set with_deleted to false by default for GET /account[s]
 -- openapi/dbv0.0.38 - add with_deleted input to GET /account[s].


So, this is expected behavior.

I'm closing this as infogiven, but don't hesitate to ask if you have more questions.