Description of problem: Subresource actions are not currently responding in the API. For example, a VM retrieved through: /api/services/:service_id/vms/:vm_id will list actions: "actions":[ {"name":"deploy postgresql", "method":"post"," href":"http://localhost:3000/api/services/10000000000570/vms/10000000001658"},{"name":"create aws elb", "method":"post", "href":"http://localhost:3000/api/services/10000000000570/vms/10000000001658"},{"name":"test ansible","method": "post","href":"http://localhost:3000/api/services/10000000000570/vms/10000000001658"},{"name":"register with satellite 6","method":"post","href":"http://localhost:3000/api/services/10000000000570/vms/10000000001658"} ] but when calling those actions, {"error":{"kind":"bad_request","message":"No actions are supported for vms resource","klass":"Api::BadRequestError"}} This is occurring because the routes are directing to the collection controller rather than the subcollection controller. The original issue that brought this to light: https://bugzilla.redhat.com/show_bug.cgi?id=1454910 Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Assigning to Tim as he as already started work on this issue.
I'm going to close this as not a bug - since actions were designed to be implemented on the resource/subresource level (and have not been implemented at the subresource level in the case of these examples), I think it is safe to assume this is working as intended. I think that if the root cause of https://bugzilla.redhat.com/show_bug.cgi?id=1454910 is addressed (the links in the response are pointing incorrectly to subresources) then this would cease to be an issue.