Hi, Our development team encountered several slurmrestd 0.0.37 Open API issues on Slurm 22.05.0-0pre1 through the master branch at 3:19pm, January 21st. Previously, we tested out the tagged Slurm 21-8-5-1 version and encountered the same issues described below. Issues: 1. When submitting an API request to slurmrestd to save a QOS record, we cannot set “GrpSubmit” and “MaxJobsAccrue” through the available API fields. 2. When submitting an API request to slurmrested to save an association record, we cannot set “MaxJobs”, “MaxSubmit”, “MaxJobsAccrue”, and “qos” through the available API fields. 3. When submitting an API request to slurmrested to update an existing association record, setting the API fields to “-1” does not reset or change the values to the default value of each field. 4. When submitting an API request to slurmrested to update an existing account record, setting the API fields to “-1” does not reset the values of “description” and “organization”. Instead these fields get the value “-1” 5. When submitting an API request to slurmrested to update an existing association record, changing the value of fields should result in new field values. However, no field values change. 6. It does not appear that DELETE works either Note all of these were POST requests, although PATCH is probably more appropriate for updates (but that gives a 400). We can provide the specific API POST bodies and URIs we used to produce these issues if that would help narrow down the problems. Thank you for your help!
(In reply to Matt Ezell from comment #0) > 1. When submitting an API request to slurmrestd to save a QOS record, we > cannot set “GrpSubmit” and “MaxJobsAccrue” through the available API fields. This fix is upstream for 21.05.6 for bug#12796. We hadn't updated the ticket due to some internal discussions about when and what should be added to the rest OpenAPI specification after an `x.x.0` release along with possibly changing the name schema for dbv0.0.38 to match the existing struct names. > 2. When submitting an API request to slurmrested to save an association > record, we cannot set “MaxJobs”, “MaxSubmit”, “MaxJobsAccrue”, and “qos” > through the available API fields. Please verify the fix for bug#12796 also covers these fields: > https://github.com/SchedMD/slurm/commit/08a4f49ac99acce0f20df0ae1719723039b6c532#diff-4c9882fd426a5721d9a9145ff4b694a5374ec2fbd20039c99e4264a7a5326741R55-R57 > 3. When submitting an API request to slurmrested to update an existing > association record, setting the API fields to “-1” does not reset or change > the values to the default value of each field. This sounds like a dup of bug#13047 or bug#13092. Was a ticket submitted for this? I'm currently working on a patch for it. > 4. When submitting an API request to slurmrested to update an existing > account record, setting the API fields to “-1” does not reset the values of > “description” and “organization”. Instead these fields get the value “-1” Same as #3 > 5. When submitting an API request to slurmrested to update an existing > association record, changing the value of fields should result in new field > values. However, no field values change. Is there a bug open for this? I suspect it is also a duplicate of #3. > Note all of these were POST requests, although PATCH is probably more > appropriate for updates (but that gives a 400). Please note this reply in bug#12944: (In reply to Nate Rini from bug#12944 comment #4) > (In reply to azoshima from bug#12944 comment #0) > > We throw the following request to api (there is no PUT method available in > > slurmrestd, so we did POST request) > > PUT vs POST is a little arbitrary here. POST was chosen since you're giving > a new change request instead of modifying an existing object. slurmrestd is > only a translator and is sending a new change request to slurmdbd in this > case. Same logic applies to PATCH (rfc5789) but I do see your point here. > This specification defines the new HTTP/1.1 [RFC2616] method, PATCH, which is used to apply partial modifications to a resource. I also find it interesting the version of curl I have installed locally doesn't support '-X PATCH'. > 6. It does not appear that DELETE works either Is there a bug open for this? Please provide an example for this in that ticket and the bug#. > We can provide the specific API POST bodies and URIs we used to produce these issues if that would help narrow down the problems. Thanks for bringing these issues to our attention. We are working on the known ones already.
(In reply to Nate Rini from comment #2) > This fix is upstream for 21.05.6 for bug#12796. Aaron said he tested this with "master branch at 3:19pm, January 21st" which should have those patches. > Please verify the fix for bug#12796 also covers these fields: Same as above > This sounds like a dup of bug#13047 or bug#13092. Was a ticket submitted for > this? I'm currently working on a patch for it. Those appear to be internal, but this is ORNL's first time reporting this issue. > > 5. When submitting an API request to slurmrested to update an existing > > association record, changing the value of fields should result in new field > > values. However, no field values change. > > Is there a bug open for this? I suspect it is also a duplicate of #3. This is ORNL's first report of the issue. > > 6. It does not appear that DELETE works either > > Is there a bug open for this? Please provide an example for this in that > ticket and the bug#. This is ORNL's first report of the issue. Do you want me to split out the "first report" issues each as a separate ticket?
(In reply to Matt Ezell from comment #3) > (In reply to Nate Rini from comment #2) > > This fix is upstream for 21.05.6 for bug#12796. > > Aaron said he tested this with "master branch at 3:19pm, January 21st" which > should have those patches. > > > Please verify the fix for bug#12796 also covers these fields: > > Same as above Please update bug#12796 with your findings and we can continue on this there. > Do you want me to split out the "first report" issues each as a separate > ticket? I was planning to do it but you're more than welcome. Splitting them out will make it easier to track each issue.
(In reply to Nate Rini from comment #4) > > Do you want me to split out the "first report" issues each as a separate > > ticket? > > I was planning to do it but you're more than welcome. Splitting them out > will make it easier to track each issue. Are you going to open those tickets? Please make sure to attach the slurmrestd logs and the requests sent when/if you do.
Looks like the per-issue tickets are getting submitted. I'm going to close this one and pursue the bugs in those.
