Ticket 16485

Summary:	requesting user information, results (associations) doesn't match 'sacctmgr'
Product:	Slurm	Reporter:	Greg Wickham <greg.wickham>
Component:	slurmrestd	Assignee:	Marshall Garey <marshall>
Status:	RESOLVED INFOGIVEN	QA Contact:
Severity:	4 - Minor Issue
Priority:	---
Version:	22.05.7
Hardware:	Linux
OS:	Linux
Site:	KAUST	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:	---
Attachments:	JSON dump of results from REST query

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.