Specific semantic of Client.Create()

[Saggi Mizrahi]

Hi,

We've recently added a new version to our CRDs.
We've saw a change in behavior for client.Create() and were trying to figure out what is the correct semantic.

Some of our code does this

obj = &v1beta2.Object{
   Spec: ...
   Status: ...
}

client.Create(ctx, obj) client.Status().Update(ctx, obj)

Before we added a new version this used to work.
Now obj.Status is zeroed after create.

On one hand this makes sense as the created object does actually a zeroed status since everything in obj.Status was ignored during creation.

On the other hand, this used to work.

We're trying to figure out if this some bug\misconfiguration on our end  or is the value of a subresource might actually change after create.

storage version is v1, the operations are performed on v1beta2 objects and the we do see the converters working properly.

Thanks

[Joel Speed]

Hi,

This is likely because of Kube API sub resources (an advanced topic within the Kube docs).

The upshot is that you can denote on the CRD yaml that a particular path within your CRD is a sub resource. Common examples of this are the status and scale sub resources.

When a sub resource is defined, it means that you must use a separate sub resource client to interact with that resource, as you’ve observed already.

It prevents updates to the spec and status at the same time, as typically, these would only be updated by separate consumers (eg user updates spec, controller updates status), this creates a nice separation and prevents possible mistakes (eg an end user wiping out the status inadvertently).

I suspect what has happened in your case is that you’ve enabled the status sub resource on your new version, where it wasn’t enabled on the old version.

When you use the controller runtime client, it restores whatever the response is from the API into the object you pass into it. This is why you are seeing obj.Status zeroed after create, it matches what is on the API Server. This is intended behaviour as far as I’m aware.

If you need to make sure the status is set correctly after create, my advice would be to take a copy of the status before create, then restore it, then apply the status update.

Eg.

originalStatus := obj.Status.DeepCopy()

client.Create(ctx, obj)

obj.Status = originalStatus

client.Statut().Update(ctx, obj)

Regards,

Joel

--

Joel Speed

He/Him

Principal Software Engineer

Red Hat

--
You received this message because you are subscribed to the Google Groups "kubebuilder" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubebuilder...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubebuilder/0fbe8748-6bab-41e8-9dd7-07a2189d0089n%40googlegroups.com.

[Saggi Mizrahi]

Thanks for the reply,

We actually had a subresource defined all along.
While I was waiting for the reply we decided to upgrade container-runtime from 0.9 to 0.11.
This started clearing the status field consistently instead of just the CRD with multiple versions.
Must have been some bug in 0.9.0 that caused it to not be cleared originally.

We are now fixing our code.

Thanks again for your help

You received this message because you are subscribed to a topic in the Google Groups "kubebuilder" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/kubebuilder/egiVciTeA9U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to kubebuilder...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubebuilder/9024F672-C670-4FD5-A6AF-B353017B724D%40redhat.com.

[Stefan Büringer]

Hi,

I think this was changed through this PR: https://github.com/kubernetes-sigs/controller-runtime/pull/1640

Regards,
Stefan