| Summary: | [REST API] Use status code 422 for resource allocation issues (gears, # of apps) | ||
|---|---|---|---|
| Product: | OKD | Reporter: | Clayton Coleman <ccoleman> |
| Component: | Pod | Assignee: | Abhishek Gupta <abhgupta> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | libra bugs <libra-bugs> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 2.x | CC: | abhgupta, rmillner, xtian |
| Target Milestone: | --- | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | rhc-0.94.3-1 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-06-25 18:27:05 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Clayton Coleman
2012-02-14 15:19:41 UTC
How about a 409 Conflict code instead. 507 seems to imply that there is not enough storage on the system to store the resource. Also 5xx series are generally reserved for server errors whereas 4xx series are for client/app errors. I think we could do that, IF we can sufficiently distinguish between the various failure states for this vs other uses. The primary one I'm thinking of is optimistic locking via etag and If-Match or similar, for which 409 is explicitly called out in the spec. ------ The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required. Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type. ^^^ last one I think I do prefer a 4xx over a 5xx. There are a few sites out there using one or the other - if you think 409 works better I'm on board. We decided to return 422 in case of such failures. Verified this on devenv_1827, it returns 422 if the user reaches gear limit #curl -i -k -H "Accept: application/xml" --user "xtian+t100:1" https://ec2-107-20-92-208.compute-1.amazonaws.com/broker/rest/domains/domaindev003/applications -d name=rubyapp1 -d cartridge=ruby-1.8 -d scale=true -X POST HTTP/1.1 422 Unprocessable Entity Date: Mon, 11 Jun 2012 06:07:29 GMT Server: Apache/2.2.15 (Red Hat) X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 3.0.4 X-UA-Compatible: IE=Edge X-Runtime: 15.998641 Cache-Control: no-cache Location: /broker/rest/api Status: 422 Content-Type: application/xml; charset=utf-8 Vary: Accept-Encoding,User-Agent Strict-Transport-Security: max-age=15768000, includeSubDomains ProxyTime: D=16003890 Transfer-Encoding: chunked <?xml version="1.0" encoding="UTF-8"?> <response> <type nil="true"></type> <messages> <message> <field nil="true"></field> <text>Failed to create application rubyapp1 due to:Failed: Either application limit has already reached or domain doesn't exist for 'xtian+t100'</text> <exit-code>104</exit-code> <severity>error</severity> </message> </messages> <version>1.0</version> <status>unprocessable_entity</status> <data> <datum nil="true"></datum> </data> <supported-api-versions> <supported-api-version>1.0</supported-api-version> </supported-api-versions> </response> |