-
Notifications
You must be signed in to change notification settings - Fork 40.6k
DELETE requests for some objects get response data with Object instead of Status object #59501
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
/sig api-machinery |
That's an issue with the documentation (and possibly the openapi doc). Returning the deleted object is intentional. |
Thanks @liggitt. If the defined behavior is that the deleted 'Pod' object should be returned then there is definitely a bug in docs as well as the swagger spec (and more?). The swagger spec shows that the DELETE response is expecting a 'Status' object as well: |
The DELETE Job endpoint has the same problem (DELETE /apis/batch/v1/namespaces/{namespace}/jobs/{name}). The documentation states a Status response, but it is actually the deleted Pod. FWIW, these documentation issues/bugs cause exceptions in the Kubernetes Java client (kubernetes-client/java#205). |
/sub |
this is true for all types that set
|
it does not always return the object though. sometimes status is returned instead. |
Status is always a valid option to be returned (401, 403, 404, 500 errors always return Status objects) |
It's a known issue kubernetes-client/java#86 (comment), as @kondapally1989 pointed out in kubernetes-client/java#205 ref #25716 |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle rotten |
Related to kubernetes#59501 Maybe related to kubernetes/enhancements#1263
Related to kubernetes/kubernetes#59501 Maybe related to kubernetes/enhancements#1263 Kubernetes-commit: 4d33d837c8be778044d50755de83f8738e957c13
/kind bug
What happened:
DELETE request for pod resource is returning the entire pod resource in the response instead of the Status resource.
What you expected to happen:
Expecting the serialized response data to contain the Status resource instead of the Pod resource.
Here is the response from the API server:

Expecting 'Status' response according to the API documentation:
https://v1-7.docs.kubernetes.io/docs/api-reference/v1.7/#delete-58
How to reproduce it (as minimally and precisely as possible):
Delete a Pod using a client where the HTTP call can be traced. Observe the JSON response.
Anything else we need to know?:
Environment:
kubectl version
):Master: Debian GNU/Linux 8 (jessie)
Agent: windows (windows server 2016 datacenter)
uname -a
):Master: 4.4.0-112-generic
Agent: 10.0 14393 (14393.2007.amd64fre.rs1_release.171231-1800)
The text was updated successfully, but these errors were encountered: