This handles canceling the request after the test completes, cleaning
up resources on the client and server.
Kubernetes-commit: 080d6f9ead740ec1358e320e388f79cc4de97697
The canonical import for json-patch v4 is
gopkg.in/evanphx/json-patch.v4 (see
https://github.com/evanphx/json-patch/blob/master/README.md#get-it for
reference).
Using the v4-specific path should also reduce the risk of unwanted v5
upgrade attempts, because they won't be offered as automated upgrades
by dependency upgrade management tools, and they won't happen through
indirect dependencies (see
https://github.com/kubernetes/kubernetes/pull/120327 for context).
Signed-off-by: Stephen Kitt <skitt@redhat.com>
Kubernetes-commit: 5300466a5c8988b479a151ceb77f49dd00065c83
* add testcase with negative index
* exercise successful negative index patching
* use different values for testing
Co-authored-by: Chris Bandy <bandy.chris@gmail.com>
---------
Co-authored-by: Chris Bandy <bandy.chris@gmail.com>
Kubernetes-commit: 83ff8a2f49f820fb355b24c65b8629710dca8a54
Rename the apiserver_request_body_sizes metric to
apiserver_request_body_size_bytes to conform with Prometheus best
practices.
This can be done safely without deprecation because that metric wasn't
registered before.
Signed-off-by: Damien Grisonnet <dgrisonn@redhat.com>
Kubernetes-commit: 08006c842fd6a584bb8e2511587c999ffe7ced9d
Implements server side field validation behind the
`ServerSideFieldValidation` feature gate. With the
feature enabled, any create/update/patch request
with the `fieldValidation` query param set to
"Strict" will error if the object in the request
body have unknown fields. A value of "Warn"
(also the default when the feautre is enabled)
will succeed the request with a warning.
When the feature is disabled (or the query param
has a value of "Ignore"), the request will succeed
as it previously had with no indications of any
unknown or duplicate fields.
Kubernetes-commit: e50e2bbc889eb274ad1463a54188a2805767bfde
- as soon as a request is received by the apiserver, determine the
timeout of the request and set a new request context with the deadline.
- the timeout filter that times out non-long-running requests should
use the request context as opposed to a fixed 60s wait today.
- admission and storage layer uses the same request context with the
deadline specified.
we use the default timeout enforced by the apiserver:
- if the user has specified a timeout of 0s, this implies no timeout on the user's part.
- if the user has specified a timeout that exceeds the maximum deadline allowed by the apiserver.
Kubernetes-commit: e416c9e574c49fd0190c8cdac58322aa33a935cf
apiserver dedups and adds warning in CREATE/UPDATE/PATCH requests;
also handles duplication caused by mutating admission.
Kubernetes-commit: 8bcf34a203efa596ac3b65da9afd6b6c764e78a9
- as soon as a request is received by the apiserver, determine the
timeout of the request and set a new request context with the deadline.
- the timeout filter that times out non-long-running requests should
use the request context as opposed to a fixed 60s wait today.
- admission and storage layer uses the same request context with the
deadline specified.
Kubernetes-commit: 83f869ee1350da1b65d508725749fb70d0f535f2
RequestScope is a large struct and causes stack growth when we pass
it by value into multiple stack levels. Avoid the allocations for
this read only struct by passing a pointer.
Kubernetes-commit: 8fede0b18a81a6fb1acc1a48857f482857c25286
builds on #62868
1. When the incoming patch specified a resourceVersion that failed as a precondition,
the patch handler would retry uselessly 5 times. This PR collapses onto GuaranteedUpdate,
which immediately stops retrying in that case.
2. When the incoming patch did not specify a resourceVersion, and persisting to etcd
contended with other etcd updates, the retry would try to detect patch conflicts with
deltas from the first 'current object' retrieved from etcd and fail with a conflict error
in that case. Given that the user did not provide any information about the starting version
they expected their patch to apply to, this does not make sense, and results in arbitrary
conflict errors, depending on when the patch was submitted relative to other changes made
to the resource. This PR changes the patch application to be performed on the object retrieved
from etcd identically on every attempt.
fixes#58017
SMP is no longer computed for CRD objects
fixes#42644
No special state is retained on the first attempt, so the patch handler correctly handles
the cached storage optimistically trying with a cached object first
Kubernetes-commit: fbd6f3808480d27a83643e82a11c217601b76cbc
This is the combination of a series of changes which individually don't
make any behavioral changes. The original commits are preserved in my
own fork in the refactor-patch-complete branch, as when squashed this is
impossible to review.
This turned a big function with lots of parameters and closures into an
object with multiple functions, fewer closures and more well documented
state transitions.
Kubernetes-commit: 349a99b80e7e6c0c92218c814ae0858fd71609fc
Marek Siarkowicz
Karl Isenberg
Tim Hockin
Stephen Kitt
Vandit Singh
Damien Grisonnet
Alexander Zielenski
David Ashpole
Han Kang
Wojciech Tyczyński
Kevin Delgado
Abu Kashem
Rajalakshmi-Girish
Jordan Liggitt
Haowei Cai
David Eads
Joe Betz
zuoxiu.jm
Clayton Coleman
Mehdy Bohlool
jennybuckley
Antoine Pelisse
Andrew Kim
Yang Li
Cao Shufeng
xuzhonghu
Mikhail Mazurskiy
Dr. Stefan Schimanski
hangaoshuai
Jordan Liggitt
Daniel Smith
Mike Danese