Commit dd897a55 authored by Kubernetes Submit Queue's avatar Kubernetes Submit Queue Committed by GitHub

Merge pull request #46536 from deads2k/crd-07-deflake

Automatic merge from submit-queue try to deflake CR watches in tests Fixes https://github.com/kubernetes/kubernetes/issues/46446 I've added a comment trying to explain the reasoning in the code. Without being able to expose the RV of the cache, I can't think of a reliable way to do it. Even if you tried experimenting with a watch, it essentially does this since you'd be waiting to not get an error.
parents f7a1f102 8170cf0f
......@@ -275,6 +275,17 @@ func (r *crdHandler) getServingInfoFor(crd *apiextensions.CustomResourceDefiniti
r.restOptionsGetter,
)
// When new REST storage is created, the storage cacher for the CR starts asynchronously.
// REST API operations return like list use the RV of etcd, but the storage cacher's reflector's list
// can get a different RV because etcd can be touched in between the initial list operation (if that's what you're doing first)
// and the storage cache reflector starting.
// Later, you can issue a watch with the REST apis list.RV and end up earlier than the storage cacher.
// The time window is really narrow, but it can happen. The simplest "solution" is to wait
// briefly for the storage cache to start before we return out new storage so its more likely that we'll have valid
// resource versions for the watch cache. We don't expose cache status outside of the caching layer
// so I can't think of way to determine it reliably.
time.Sleep(1 * time.Second)
parameterScheme := runtime.NewScheme()
parameterScheme.AddUnversionedTypes(schema.GroupVersion{Group: crd.Spec.Group, Version: crd.Spec.Version},
&metav1.ListOptions{},
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment