The reason for the issue is that the apiserver uses the Scheme in the
global variable pkg/api/legacyscheme/scheme.go, and registers the
DeleteOptions corresponding to each APIGroup in the Scheme. But
DeleteOptions in meta.k8s.io/v1 is not registered, resulting
in a notRegisteredErr.
Use metainternalversionscheme.Codecs as Serializer
Kubernetes-commit: e7d7f4a9e56fe5d9c10da437787118fe9ea9e5af
- Run hack/update-codegen.sh
- Run hack/update-generated-device-plugin.sh
- Run hack/update-generated-protobuf.sh
- Run hack/update-generated-runtime.sh
- Run hack/update-generated-swagger-docs.sh
- Run hack/update-openapi-spec.sh
- Run hack/update-gofmt.sh
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
Kubernetes-commit: a9593d634c6a053848413e600dadbf974627515f
add short-circuiting logic for long comaprison
replace timestamps rather than doing a full managed fields deepcopy
add guard
Kubernetes-commit: 7233538008489c189d09bb042fbabca97d9cdbaf
Before:
Create()
BeginCreate()
BeforeCreate()
init UID <---------------------
strategy code
After:
Create()
init UID <-------------------------
BeginCreate()
BeforeCreate()
strategy code
This also wipes UID early (suggested by David) and asserts it is set in
BeforeCreate().
Kubernetes-commit: 5615de51f9e768dd01d7fe49a48e8db756bd8ac8
It allows us to allocate a single buffer for the entire watch session and release it when a watch connection is closed.
Previously memory was allocated for every object serialization putting a lot of pressure on GC and consuming more memory than needed.
Kubernetes-commit: eda1b0c68ec166ee52c50e4a6ab682ce7227b6a5
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
addresses feedback by adding a test to make sure that the manager pipeline will not return the same instance used as input, and that the output does not input managedFields
Kubernetes-commit: 68e175ef68eff1351917ac206fb29abe42128062
drop the managed fields of the objects from the audit entries when we
are logging request and response bodies.
Kubernetes-commit: bbc59348318c29199e23b27981fb56436ac68705
Replace the forked totalAnnotationSizeLimitB with
apimachineryvalidation.TotalAnnotationSizeLimitB.
Kubernetes-commit: 55ff96301797a503b6ee1d09f0eb2ffc827f01b1
To support CSA and SSA interoperability, SSA updates the CSA
last-applied annotation.
This change ensures we don't set a big last-applied annotation if the
value is over the annotation limits.
Also, make sure that it's possible to opt-out of this behavior by
setting the CSA annotation to "" the empty string.
Kubernetes-commit: 6054320be1e50a450e9d1e19a79caa96f2035d4d
Not all objects provide metadata. There might be extention servers that allow for creating objects without the metadata field.
This PR changes the managedFileds admission to deal with objects without the metadata field.
Object without that field will be passed directly to the wrapped admission controller for further validation.
Kubernetes-commit: 3dbaf305ae1e52105a338987f3770ff104def68b
This is to prevent the ScaleHandler to drop the entry. In this way
entries just get ignored.
Kubernetes-commit: 5b666a61a170f61c7e223085478b24a03612fa99
- Test all versions to make sure each resource version is in the
mappings
- Fail when request info contains an unrecognized version. We have tests
that guarantee that all known versions are in the mappings. If we
get a version in request info that is not there we should fail fast to
prevent inconsistent behaviour (e.g. for some reason the mappings is
not up to date).
Ensure all known versions are in mappings
Kubernetes-commit: 09649e58b5a1368929e194991a763afc8011795e
This field is useful to namespace the managed field entries of a
subresource and differentiate them from the ones of the main resource.
Kubernetes-commit: 862d256195adf3be5475b1a6935e5feb78f884a5
- when we forward the request to the aggregated server, set the audit
ID in the new request header. This allows audit logs from aggregated
apiservers to be correlated with the kube-apiserver.
- use the audit ID in the current tracer
- use the audit ID in httplog
- when a request panics, log an error with the audit ID.
Kubernetes-commit: b607ca1bf3e1cf6152c446ea61ac7fdd9014e1f1
Ensure that all label selectors are treated as atomic values,
to exclude situations when selectors are being corrupted by
different actors attempting to apply their overlapping definition
for this field with server-side-apply.
Kubernetes-commit: d8a7764b6396b90313ae7bd50a845f4da4705d67
Adds and implements ResetFieldsProvder interface in order to ensure that
the fieldmanager no longer owns fields that get reset before the object
is persisted.
Co-authored-by: Kevin Wiesmueller <kwiesmul@redhat.com>
Co-authored-by: Kevin Delgado <kevindelgado@google.com>
Kubernetes-commit: a1fac8cbd9289d95db4831a83239292ed56ce59d
- 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
for CREATE and UPDATE requests, we check duplication before managedFields
update, and after mutating admission; for PATCH requests, we check
duplication after mutating admission
Kubernetes-commit: ffc54ed1d2cbf4396fcc498beeb6ad34ac3df69c
- 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
PATCH verb is used when creating a namespace using server-side apply,
while POST verb is used when creating a namespace using client-side
apply.
The difference in path between the two ways to create a namespace led to
an inconsistency when calling webhooks. When server-side apply is used,
the request sent to webhooks has the field "namespace" populated with
the name of namespace being created. On the other hand, when using
client-side apply the "namespace" field is omitted.
This commit aims to make the behaviour consistent and populates the
"namespace" field when creating a namespace using POST verb (i.e.
client-side apply).
Kubernetes-commit: 3cb510e33eecbdc37aad14f121396ccfbf5268cb
If a request tries to change managedFields, the response returns the
managedField of the live object.
Kubernetes-commit: c522ee08a3d248ec1097e3673119ffa7a4e1ef7b
previously all sorts of errors including a data race were possible because deferredResponseWriter resets the writer and returns it to the pool.
an attempt to write to a nil writer will lead to "invalid memory address or nil pointer dereference"
sharing the same instance of deferredResponseWriter might lead to "index out of range [43] with length 30" and "recovered from err index > windowEnd" errors
Kubernetes-commit: e6f98311d00f083c1b980ed7434d2e9769fa921f
- Test that client-side apply users don't encounter a conflict with
server-side apply for objects that previously didn't track managedFields
- Test that we stop tracking managed fields with `managedFields: []`
- Test that we stop tracking managed fields when the feature is disabled
Kubernetes-commit: f2deb2417a6c542c54606ab17376b26ef1552b87
- Allow client-side to server-side apply upgrade.
Ensure that a user can change management of an object from client-side apply to
server-side apply without conflicts.
- Allow server-side apply to client-side downgrade.
For an object managed with client-side apply, a user may upgrade to
managing the object with server-side apply, then decide to downgrade.
We can support this downgrade by keeping the last-applied-configuration
annotation for client-side apply updated with server-side apply.
Kubernetes-commit: e4368eb67e363d3d03f81214a8929268d2fe88ff
Paweł Banaszewski
David Ashpole
Tim Allclair
scott
Alex Zielenski
Shyam Jeedigunta
HaoJie Liu
Han Kang
Antonio Ojea
David Eads
Maciej Borsz
Davanum Srinivas
Alexander Zielenski
Artur Żyliński
Abirdcfly
Tim Hockin
Guillaume Le Biller
Daniel Smith
Sanskar Jaiswal
Kensei Nakada
Tim Bannister
Abu Kashem
Wojciech Tyczyński
Jordan Liggitt
Lukasz Szaszkiewicz
Iceber Gu
Kevin Delgado
Antonio Ojea
CKchen0726
Dr. Stefan Schimanski
Antoine Pelisse
j2gg0s
njuptlzf
Kasakaze
Julian V. Modesto
zhuangqh
Andrea Nodari
Danil-Grigorev
Kevin Wiesmueller
chymy
Alan Zhu
yoyinzyc
lala123912
Rajalakshmi-Girish
Jie Shen
Ken Sipe
Haowei Cai
Jefftree
Joe Betz
Julian V. Modesto
AkashSarda
Wei Huang
Tariq Ibrahim