jpbetz / conversion-webhook-example Goto Github PK

I didn't verify this.

In our benchmarks, we assume that we create unique CR/Endpoints objects by having timestamp in object names

metadata:
  name: barv1-{timestamp in nanosecond}

This might be a problem when we bring up goroutines to do massive creation in parallel (e.g. in LIST benchmarks). I could imagine two goroutines sending requests at the same time and one request fails due to name conflict

(the problem could be rare or not existing, given goroutines are created in serial / some underlying assumption with rest client)

to fix/mitigate: add additional bit in object name unique to each goroutine, like another count

The LIST benchmarks are using "ResourceVersion=0" in their initial counting. The watch cache count may be lagging behind the actual object count in etcd, causing the benchmark to create more than needed objects

I've seen LIST benchmark creates more than 10000 CRs

to fix: don't specify resource version in list option