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.

staging/src/k8s.io/kube-apiextensions-server/pkg/apiserver/customresource_handler.go

@@ -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{},