Description of problem: The Response of retirement request API call missing the href pointed to service_requests Id Version-Release number of selected component (if applicable): 5.11 How reproducible: Always Steps to Reproduce: After making request_retire call, The response we are getting is like below: POST https://<cfmeapi>/api/vms/<vmid> { "action" : "request_retire" } Response: { "success": true, "message": "VM id: <vm-id> name:'<vm name>' request retire", "task_id": "1000000025798", "task_href": "https://<cfmeapi>/api/tasks/1000000025798", "href": "https://<cfmeapi>/api/vms/<vmid>" } This will show the task ref: 1000000025798 and this ID has nothing related with the actual retirement task. This task seems to be related with the status of API call i.e. if the api call is 200 ok success or failed with bad request but has no reference to actual retirement request/task. The actual retirement task id verified in logs is: r1000000000005_vm_retire_task_1000000000005 here r1000000000005 is the retirement request generated after the call and 1000000000005 is the task id with reference to the requestid. To get the retirement request status, I need to check at Service -> Requests and look for valid request id and then with below request, I can see the actual retirement status i.e. GET https://<cfmeapi>/api/requests/1000000000005 This gives the actual status of the retirement request. Actual results: No href to service_requests so to track the retirement request. Expected results: There should be request reference too after making the retirement request call so that user can check the status of task after clicking the request reference. Additional info:
The reason that the request id isn't available as part of the response is because for this api call we queue the retire request (see https://github.com/ManageIQ/manageiq-api/pull/662). The problem is that the API would have to wait until the request gets queued before running the `action_result(true, desc, :task_id => task_id)` with the task id described in this bug's description. It doesn't make any sense to me to force the API to wait, which is why I'm hesitant to implement any fix for this. I would argue it's working as intended and that fixing it would be detrimental to how the API should operate in general.
I chatted with Libor about this and he agrees with me that the API shouldn't be waiting for anything to be queued. So I don't believe the way the product works currently we can fix this.
https://gitter.im/ManageIQ/api?at=5d0a41cbee09830dde8bb32d is from Jason, it's in an unrelated message about the api having an issue where service template creation waits for a task. Jason's comment is pretty clear about the fact that the API shouldn't ever be waiting for anything.
I checked on this with Alberto, the expert: "... you don't want the API to wait on anything, otherwise you can easily make the server being [sic] useless. That's why in long running operations we return the task id and reference so customers can query the task periodically for completion." I'd like to close this as not a bug.
Hello Drew, Yes, seems like it is not feasible option to have request id details in the API response. I have updated the customer with the above reason. I guess we can close it as not a bug. Thanks for checking it. Regards, Neha Chugh
Thanks, Neha for opening the ticket. I appreciate you checking to make sure the behavior is correct. Thanks, Drew for the explanation, I appreciate you taking the time to explain how it works. I'm learning more about the API calls as well.