is there a way to make client.Get to not get from cache

[chenzhiwei]

Hi, I have a case that I need to use client.Get() immediately after running client.Status().Update().

The client.Get() will get the object from cache, this is not what I want.

The implementation:

controller-runtime/pkg/client/split.go

Lines 45 to 52 in ab6131a

	// Get retrieves an obj for a given object key from the Kubernetes Cluster.
	func (d *DelegatingReader) Get(ctx context.Context, key ObjectKey, obj runtime.Object) error {
	_, isUnstructured := obj.(*unstructured.Unstructured)
	if isUnstructured {
	return d.ClientReader.Get(ctx, key, obj)
	}
	return d.CacheReader.Get(ctx, key, obj)
	}

I don't want to use CacheReader and I also can't use unstructured Object.

Is there a way to make sure client.Get() to get the realtime result? Maybe wait for cache to sync? I don't know how.

My code is something like: https://github.com/operator-framework/operator-sdk/blob/d6903be02d4e8541e777b25af0498fe31e2e41e8/internal/pkg/scaffold/controller_kind.go#L213-L219

[joelanford]

@chenzhiwei If absolutely necessary, you can use the client.Reader returned by Manager.GetAPIReader() to hit the API server directly.

Could you explain a little bit more about your use case though? There might be a better way to structure your watches and reconcile method that allows you to do what you want while still leveraging the caching benefits of the split client.

Are you fetching the same object that you just updated the status of?

[chenzhiwei]

@joelanford Thank you for your reply, my use case is:

Create/Update a CRD resource will trigger a Kubernetes Job, but there is only one Job can be running at a time.

Create/Update the CRD resource and the Job status change will both trigger a Reconcile action.

I can't find a way to distinguish the Reconcile is triggered by CRD resource or Kubernetes Job.

So I need to record the Job name in the CRD resource status to avoid multiple Jobs running at one time.

My logic is: Create CRD resource, trigger a Job and set Job name to CRD resource status, next reconcile happen, then get the Job name from CRD resource status, then consider creating or waiting the Job.

[joelanford]

I can't find a way to distinguish the Reconcile is triggered by CRD resource or Kubernetes Job.

It's generally considered a good practice to implement your Reconcile method such that it doesn't need to know what event triggered it. The Reconciler interface was specifically designed to encourage this.

So I need to record the Job name in the CRD resource status to avoid multiple Jobs running at one time.

Another good practice is to avoid reading status fields to reconstruct state since they may be incorrect or out-of-date. In your case, consider the possibility that you trigger the Job successfully, but then a failure occurs when you try to update the status. On your next reconcile, you might create another Job since the job name is not set in the CR status.

My logic is: Create CRD resource, trigger a Job and set Job name to CRD resource status, next reconcile happen, then get the Job name from CRD resource status, then consider creating or waiting the Job.

A better way to handle that would be to make the Job name (or a label value) deterministic based on the contents of the CR metadata and/or spec so that you could fetch it directly. For example, can you name the Job the same as the CR? If so, you wouldn't need to store the name in the CR status because you would always know it and be able to fetch the Job or create it if it doesn't exit.

In your case, what happens when subsequent CR updates come in when a previous Job is still running? Do you need to somehow queue up jobs for each CR change? Or is it okay to skip some CR updates and run a Job for just the most recent CR?

[chenzhiwei]

Actually I record CR spec hash and Job name to the CR status, we need both of them to handle the cases.

If the Job is running and there is another change to the CR, then the jobs will be queued and execute later.

If the Job name is same as CR, then the second update to the CR will not create the Job.

If the Job name is the CR Spec hash, then revert the CR change will not create the Job(CR hash is aaaa, then bbbb, then aaaa).

[DirectXMan12]

So, to be clear, you want to run a new job every time the CR spec changes? That's not really how Kubernetes works (although I'm a bit fuzzy on what the exact logic is here that you want).

[chenzhiwei]

Yes, the logic in my project is weird, but I still need to implement.

Thank you all, I have another way to implement this similar logic.

[vie-serendipity]

Are you fetching the same object that you just updated the status of?

@joelanford Are there any best practices for this situation besides using GetAPIReader?