Call to get namespaced resources is calling the API to retrieve them all?

[ggallen]

I seem to see this this call:

	cm := &corev1.ConfigMap{}
	err := r.Get(ctx, types.NamespacedName{Name: "sink-filters", Namespace: "kubearchive"}, cm)

Translating into this request under the covers:

https://10.96.0.1:443/api/v1/configmaps?limit=500&resourceVersion=0

Even though I have specified a name and a namespace, it seems to be trying to get all (up to 500) ConfigMaps. Is this expected behavior or is my call somehow wrong?

[troy0820]

Interesting. That's a different endpoint used for list. Are you listing the configmaps anywhere?

This is the endpoing for GET:
GET /api/v1/namespaces/{namespace}/configmaps/{name}

What version of CR are you running?

[ggallen]

@troy0820, you can see the call here.

I don't believe I call list anywhere in my operator.

Note that I am using OTEL to find the call. The only GET to ConfigMaps that I see in my output is the one I listed.

[ggallen]

My controller-runtime version:

[gallen@gallen-thinkpadp1gen5 kubearchive] (issue-780)$ grep controller-runtime go.mod
	sigs.k8s.io/controller-runtime v0.20.2
[gallen@gallen-thinkpadp1gen5 kubearchive] (issue-780)$ 

[ggallen]

Note also that I see the same behavior for all GET requests. It's not just this resource.

[bigkevmcd]

@ggallen do you see any queries that include /api/v1/configmaps and watch=true you are watching ConfigMaps if it's early on in the code, is this the caching being populated for the watch?

[ggallen]

@bigkevmcd, I'll take a look. Are you saying that I am watching ConfigMaps? Because I don't think that I did that intentionally.

[ggallen]

I don't believe there are any watches.

[sbueringer]

If you use the client from mgr.GetClient() you are using the cached client which per default internally creates an informer (including list+watch) after the first get or list call

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale