Skip to content
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

client.Get() does not zero out slice fields on CRD objects #1639

Closed
nathanperkins opened this issue Aug 21, 2021 · 1 comment · Fixed by #1640
Closed

client.Get() does not zero out slice fields on CRD objects #1639

nathanperkins opened this issue Aug 21, 2021 · 1 comment · Fixed by #1640
Assignees

Comments

@nathanperkins
Copy link

nathanperkins commented Aug 21, 2021

I've encountered some unusual behavior when using Get() on CRD objects with the controller-runtime client. When the client.Object you pass into Get() has a slice field populated with values and the object on the API server has an empty or nil slice for that field, the client does not properly zero/empty that field.

This is in contrast with the behavior when getting core objects, which does zero/empty fields as expected.

Observations

  • Empty slice fields on the API server do not empty/zero populated fields on the client.Object.
  • I confirmed this issue occurs for slice fields in ObjectMeta, Spec, and Status.
  • Populated slice fields on the API server properly update the client.Object as expected.
  • Other field types like int and string update as expected regardless of presence.
  • Empty slice fields update properly for core objects, confirmed with v1.ConfigMap.
  • I tested and confirmed on v0.7.0 and v0.9.6.

The example test below demonstrates the inconsistency.

var _ = Describe("client.Get", func() {
	ctx := context.Background()

	var (
		crdObject  *v1alpha1.CRDType
		coreObject *corev1.ConfigMap
	)

	BeforeEach(func() {
		crdObject = &v1alpha1.Type{
			ObjectMeta: metav1.ObjectMeta{
				Name:      "crd-object",
				Namespace: "default",
				// Finalizers empty.
			},
		}
		coreObject = &corev1.ConfigMap{
			ObjectMeta: metav1.ObjectMeta{
				Name:      "core-object",
				Namespace: "default",
				// Finalizers empty.
			},
		}
	})

	JustBeforeEach(func() {
		Expect(k8sClient.Create(ctx, crdObject)).Should(Succeed())
		Expect(k8sClient.Create(ctx, coreObject)).Should(Succeed())
	})

	AfterEach(func() {
		Expect(k8sClient.Delete(ctx, crdObject)).Should(Succeed())
		Expect(k8sClient.Delete(ctx, coreObject)).Should(Succeed())
	})

	It("Should overwrite slices that should be empty when getting a CRD object", func() {
		crdObject.Finalizers = []string{"1.1.1.1"}

		Expect(k8sClient.Get(ctx, client.ObjectKeyFromObject(crdObject), crdObject)).
			Should(Succeed())

		// Fails: crdObject.Finalizers is []string{"1.1.1.1"}
		Expect(crdObject.Finalizers).To(BeEmpty())
	})

	It("Should overwrite slices that should be empty when getting a core object", func() {
		coreObject.Finalizers = []string{"1.1.1.1"}

		Expect(k8sClient.Get(ctx, client.ObjectKeyFromObject(coreObject), coreObject)).
			Should(Succeed())

		// Passes.
		Expect(coreObject.Finalizers).To(BeEmpty())
	})
})
@alvaroaleman
Copy link
Member

alvaroaleman commented Aug 22, 2021

Yeah, I can confirm this. This happens because the json deserializer (caseSensitiveJSONIterator) doesn't clear the object. caseSensitiveJSONIterator is documented to behave as the stdlib deserializer except that its case sensitive and the stdlib deserializer does the same. Hence its unlikely upstream will change anything (although I personally find the stdlib behavior pretty questionable).

I presume it works with the ConfigMap as expected because we use proto there.

Seems we have to workaround this by resetting the value in at least Get() and List()

alvaroaleman added a commit to alvaroaleman/controller-runtime that referenced this issue Aug 22, 2021
Fixes kubernetes-sigs#1639

The json deserializer of the stdlib and the one from Kube which aims to
be compatible won't zero out all field types in the object it
deserializes into, for example it lets slices be if the json does not
contain that field. This means that if a non-empty variable is used for
any api call with the client, the resulting content might be a mixture
of previous content and what is on the server.

This PR adds a wrapper around the deserializer that will first zero the
target object.
alvaroaleman added a commit to alvaroaleman/controller-runtime that referenced this issue Aug 22, 2021
Fixes kubernetes-sigs#1639

The json deserializer of the stdlib and the one from Kube which aims to
be compatible won't zero out all field types in the object it
deserializes into, for example it lets slices be if the json does not
contain that field. This means that if a non-empty variable is used for
any api call with the client, the resulting content might be a mixture
of previous content and what is on the server.

This PR adds a wrapper around the deserializer that will first zero the
target object.
@alvaroaleman alvaroaleman self-assigned this Aug 22, 2021
k8s-ci-robot pushed a commit that referenced this issue Aug 26, 2021
Fixes #1639

The json deserializer of the stdlib and the one from Kube which aims to
be compatible won't zero out all field types in the object it
deserializes into, for example it lets slices be if the json does not
contain that field. This means that if a non-empty variable is used for
any api call with the client, the resulting content might be a mixture
of previous content and what is on the server.

This PR adds a wrapper around the deserializer that will first zero the
target object.
k8s-ci-robot pushed a commit to k8s-ci-robot/controller-runtime that referenced this issue Sep 9, 2021
Fixes kubernetes-sigs#1639

The json deserializer of the stdlib and the one from Kube which aims to
be compatible won't zero out all field types in the object it
deserializes into, for example it lets slices be if the json does not
contain that field. This means that if a non-empty variable is used for
any api call with the client, the resulting content might be a mixture
of previous content and what is on the server.

This PR adds a wrapper around the deserializer that will first zero the
target object.
k8s-infra-cherrypick-robot pushed a commit to k8s-infra-cherrypick-robot/controller-runtime that referenced this issue Sep 10, 2021
Fixes kubernetes-sigs#1639

The json deserializer of the stdlib and the one from Kube which aims to
be compatible won't zero out all field types in the object it
deserializes into, for example it lets slices be if the json does not
contain that field. This means that if a non-empty variable is used for
any api call with the client, the resulting content might be a mixture
of previous content and what is on the server.

This PR adds a wrapper around the deserializer that will first zero the
target object.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants