[Flaking test] unit test TestStoreListResourceVersion about kubernetes HOT 12 CLOSED

Bisected this to a8ef6e9
cc @wojtek-t

from kubernetes.

I'm not sure if this is the proper way to fix it, but setting a limit in the ListOptions deflakes the test.

Right, setting a limit when a resource version is set would delegate the list to etcd when cache is not initialized based on the KEP description.

It is due to this type of request is not that costly to etcd.

Perhaps in tests we could wait till the cache is ready in order to proceed?

Looks like it is exactly how the wait cache ready is added in https://github.com/kubernetes/kubernetes/pull/124642/files#diff-d82df65cc0625a3f621333245e76fbc801b579eedd3d266fe36eeb99366b5680.

See below

So I think we should implement this same thing in newTestGenericStoreRegistry when initializing the cacher.

from kubernetes.

Agree - waiting for cacher to be initialized when creating it here is a better fix for it:
https://github.com/kubernetes/kubernetes/blob/22512e7a3c6db15ac7a9d46edfe4563fe561418f/staging/src/k8s.io/apiserver/pkg/registry/generic/registry/store_test.go#L2448C4-L2449C1

from kubernetes.

Exposing Wait(context) method sounds fine

from kubernetes.

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

from kubernetes.

/sig api-machinery

from kubernetes.

See also https://testgrid.k8s.io/sig-release-master-blocking#ci-kubernetes-unit

https://go.k8s.io/triage?pr=1&test=k8s.io%2Fapiserver%2Fpkg%2Fregistry%2Fgeneric

from kubernetes.

/sig etcd

from kubernetes.

/assign @serathius
/cc @wenjiaswe

from kubernetes.

I'm not sure if this is the proper way to fix it, but setting a limit in the ListOptions deflakes the test.

The flakiness comes from the fact that the cache is sometimes not initialized in time which causes it to return a "too many requests".

Perhaps in tests we could wait till the cache is ready in order to proceed?

from kubernetes.

I thought about this as well, but waiting on cacher.ready.wait() is not possible outside of the cacher module, since it is a private field.

I'm thinking to either add an option WaitUntilReady to cacherstorage.Config and make cacherstorage.NewCacherFromConfig wait or add a new public method Wait(context.Context) error to Cacher.

Do you guys have a better idea? Thanks.

from kubernetes.

I have pushed the changes we discussed. Thank you all for your guidance.

from kubernetes.