This significantly reduces the surface area of the fieldmanager package
by hiding all the private "managers" objects, as well as the interface
that was made specifically for these. There is no reason to configure
these.
Kubernetes-commit: adfc65ec23292ebd95d96727654acd8e8e0452a5
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
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
If a request tries to change managedFields, the response returns the
managedField of the live object.
Kubernetes-commit: c522ee08a3d248ec1097e3673119ffa7a4e1ef7b
- 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
Lowers probability of managedField population on create/update to 0%
until serialization/normalization issues are resolved
Kubernetes-commit: ba23aa98f6574bd1f9781f0d3e61d0496f16fc53
This is super expensive and not needed at all since we don't have to
reparse the entire object. Remove all allocations but the first one.
Kubernetes-commit: 31c644a1e79c685b52683ed1e84964186a37f3ff
Errors on updates are bad because they usually come from controllers and
it's very hard to take actions on them. We also don't want to start
breaking kubernetes clusters if something in a schema happens a way we
didn't foresee (even though we've tried to be diligent and test as much
as possible, these can still happen).
Log an identifiable error when they happen. Ideally people can look in
the logs to find these and report them, or providers can look for these
in logs and make sure they don't happen.
Only conversion to internal types are going to be logged and ignored.
It means that we're still failing for:
- Version conversions. If we can't convert the object from one version
to another,
- Unions. If we can't normalize the union,
- Invalid MangedFields sent in the object. If something has changed the
ManagedFields to an invalid value.
- Failure to serialize the manager information, this really shouldn't
happen.
- Encoding the ManagedFields
Kubernetes-commit: 4e32d183d0257c9f6c7f8342d1f9aa7f28458f2f
What is the problem being solved?
https://github.com/kubernetes/kubernetes/pull/75135
Currently version compatibility is not being checked in server side apply between the patch object and the live object. This is causing a merge that will error to be run and the apiserver returns a 500 error. The request should fail if the apiVersion provided in the object is different from the apiVersion in the url, but it should fail before trying to merge, and be a 4xx error. Probably a bad request error.
Why is this the best approach?
The approach of serializing the patch byte array and then checking for version equality with the already serialized live object is the simplest and most straightforward solution.
Kubernetes-commit: d5bd17cda0c134e5ef5c03c3eac79a9ce4e18003
And add a corresponding flag in kubectl (for apply), even though the
value is defaulted in kubectl with "kubectl".
The flag is required for Apply patch-type, and optional for other PATCH,
CREATE and UPDATE (in which case we fallback on the user-agent).
Kubernetes-commit: eb904d8fa89da491f400614f99458ed3f0d529fb
refactor fieldstrip and update tests
add checks and remove empty fields
shorten test and check for nil manager
fix gofmt
panic on nil manager
Kubernetes-commit: 9082cac48240ebc316015dabb466e5b24a113dc1