[nova][dev] Which response code should be returned when migrate is called but the src host is offline?
Hello all, I can't seem to settle on an answer for $subject as part this bugfix: compute: Reject migration requests when source is down https://review.openstack.org/#/c/623489/ 409 suggests that the user is able to address the issue while 503 suggests that n-api itself is at fault. I'd really appreciate peoples thoughts on this given I hardly ever touch n-api. Thanks in advance, -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
On Tue, 12 Feb 2019 at 18:06, Lee Yarwood <lyarwood@redhat.com> wrote:
Hello all,
I can't seem to settle on an answer for $subject as part this bugfix:
compute: Reject migration requests when source is down https://review.openstack.org/#/c/623489/
409 suggests that the user is able to address the issue while 503 suggests that n-api itself is at fault. I'd really appreciate peoples thoughts on this given I hardly ever touch n-api.
I don't think it means n-api is at fault, I think it means that nova, as a whole, is temporarily unable to fulfil the request for reasons which can't be resolved using the API, but might be fixed if you wait a bit. The weird thing about this specific request is that, being an admin api, the person you might be waiting on to fix it might be yourself. It's still OOB, though: compute host down isn't something you can fix using the API. 409 to me means you raced with something, or something is in the wrong state, and you need to go do other things with the API before coming back here and trying again. 503 to me means we can't do it no matter what you do because, well, 'Service Unavailable'. Which it is, because the compute host is down. This isn't a hill I'm prepared to die on, though, just my 2c ;) Matt -- Matthew Booth Red Hat OpenStack Engineer, Compute DFG Phone: +442070094448 (UK)
although i don't know the nova internals that well, i will respond with my sig api hat on. On Tue, Feb 12, 2019 at 1:28 PM Matthew Booth <mbooth@redhat.com> wrote:
I don't think it means n-api is at fault, I think it means that nova, as a whole, is temporarily unable to fulfil the request for reasons which can't be resolved using the API, but might be fixed if you wait a bit. The weird thing about this specific request is that, being an admin api, the person you might be waiting on to fix it might be yourself. It's still OOB, though: compute host down isn't something you can fix using the API. 409 to me means you raced with something, or something is in the wrong state, and you need to go do other things with the API before coming back here and trying again. 503 to me means we can't do it no matter what you do because, well, 'Service Unavailable'. Which it is, because the compute host is down.
i tend to concur with this reading as well. for me, when thinking about status codes in general i like to keep this in miind: 4xx means something has gone wrong but the client might be able to fix it by changing the request (this could mean many things), 5xx means that something has gone wrong on the server-side and continued requests will not "fix it". so, under the given example, i would expect a 5xx status code if the server is unable to respond to my request /regardless/ of how i format it or what uri i am accessing. just 2 more c to the pile =) peace o/
On Feb 12, 2019, at 12:56 PM, Michael McCune <msm@redhat.com> wrote:
so, under the given example, i would expect a 5xx status code if the server is unable to respond to my request /regardless/ of how i format it or what uri i am accessing.
I view 503 as “something is wrong with the server” [0], and 409 as “something is wrong with the resource” [1]. In the scenario described, there is nothing wrong at all with the servers handing the request. There is, however, a problem with the resource that the request is trying to work with. Of course, the advice in the docs to include enough in the payload for the client to understand the nature of the problem is critical, no matter which code is used. [0] https://tools.ietf.org/html/rfc7231#section-6.6.4 [1] https://tools.ietf.org/html/rfc7231#section-6.5.8 -- Ed Leafe
On Tue, Feb 12, 2019 at 2:20 PM Ed Leafe <ed@leafe.com> wrote:
In the scenario described, there is nothing wrong at all with the servers handing the request. There is, however, a problem with the resource that the request is trying to work with. Of course, the advice in the docs to include enough in the payload for the client to understand the nature of the problem is critical, no matter which code is used.
++, i think this nuance is crucial to crafting the proper response from the server. peace o/
On 12-02-19 14:35:48, Michael McCune wrote:
On Tue, Feb 12, 2019 at 2:20 PM Ed Leafe <ed@leafe.com> wrote:
In the scenario described, there is nothing wrong at all with the servers handing the request. There is, however, a problem with the resource that the request is trying to work with. Of course, the advice in the docs to include enough in the payload for the client to understand the nature of the problem is critical, no matter which code is used.
++, i think this nuance is crucial to crafting the proper response from the server.
peace o/
Right, hopefully the current payload is useful enough. I can't include the actual hostname as the resize API that is also changed as a result of this is not admin only and we don't want to leak hostnames to users. For now I'm going to stick with 409 unless anyone can point to an example in n-api of us using 5xx for something similar. Thanks again, -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
participants (4)
-
Ed Leafe
-
Lee Yarwood
-
Matthew Booth
-
Michael McCune