kubernetes: Server-Side Apply should return a proper http status when validation fails

Server-Side Apply has different constraints for updating the managed fields and applying than typical objects, and sometimes the discrepency can cause problem.

When trying to update the managedFields, if the object doesn’t validate, then the whole managedFields list is removed, the error is ignored as to continue with the normal process. But then such an object can’t ever be applied, since it can’t be converted into the type of objects that server-side apply uses.

Right now, when this happens, the server-side apply request fails with a generic 500. We’re trying decide what code should be returned in that case (solving the problem of applying such an object is a separate issue), so that the client can possibly try a different way. Here’s the problem though: there is fundamentally nothing wrong with the client request, so 4xx doesn’t really fit, and yet, the client should take an action since there isn’t much we can do server-side, so a 5xx doesn’t really fit either.

cc @thockin @alculquicondor @aojea @jpbetz

About this issue

  • Original URL
  • State: open
  • Created a year ago
  • Comments: 20 (18 by maintainers)

Most upvoted comments

https://http.dev/422

422 Unprocessable Content The HyperText Transfer Protocol (HTTP) 422 Unprocessable Content response status code indicates that the server understands the content type of the request entity, and the syntax of the request entity is correct, but it was unable to process the contained instructions.

in the metav1.Status

/unassign gdhuper

Please wait for a conclusion before sending a PR.

From https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/409:

The HTTP 409 Conflict response status code indicates a request conflict with the current state of the target resource.

That’s also pretty close to what we have.