It turned out that there were lots of unnecessary accessor functions being called locking and unlocking the cond which are not needed because Wait() automatically unlocks and locks the cond for us and best practice says we should run it in a for checking for the condition (so this is what I have done).
Kubernetes-commit: 2b12df56b0be93bc2cac7c5a66342c0ffaa72311
To be able to write more precise unit tests in the future
Change-Id: I8f45947dfacca501acd856849bd978fad0f735cd
Kubernetes-commit: dad8454ebb87ba7af897537db6d34033127bbfef
- Run hack/update-codegen.sh
- Run hack/update-generated-device-plugin.sh
- Run hack/update-generated-protobuf.sh
- Run hack/update-generated-runtime.sh
- Run hack/update-generated-swagger-docs.sh
- Run hack/update-openapi-spec.sh
- Run hack/update-gofmt.sh
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
Kubernetes-commit: a9593d634c6a053848413e600dadbf974627515f
Two simple choices for workqueues do not document that they do not emit
metrics. Using their named variants fixes this, but was undocumented.
Change-Id: I100ad08a4859513987941ed35d12abb4cbb39873
Kubernetes-commit: f468bee672b0ccf9b97a85f17ec1f5645aced926
See https://github.com/grpc/grpc-go/issues/4758 for a real world example
of this leaking 2gb+ of data.
Basically, when we do `q.queue[1:]` we are just repositioning the slice.
The underlying array is still active, which contains the object formerly
known as `q.queue[0]`. Because its referencing this object, it will not
be GCed. The only thing that will trigger it to free is eventually when
we add enough to the queue that we allocate a whole new array.
Instead, we should explicitly clear out the old space when we remove it
from the queue. This ensures the object can be GCed, assuming the users'
application doesn't reference it anymore.
Kubernetes-commit: 2a34801168dc1c70ba25b1d4200b534bf515cbc2
Problem:
When calling newQueue metrics can be of type noMetrics when just calling
New. When doing this a new goroutine is created to update the metrics
but in this case there are no metrics so it's just creating goroutines
that don't do anything but consume resources.
Solution:
If the incoming metrics is of type noMetrics, don't start the goroutine
Kubernetes-commit: de021396f81ff438899297a6f464c70113b58475
All queue ShutDown() calls should be able to be invoked multiple times.
```
Observed a panic: "close of closed channel" (close of closed channel)
/go/src/github.com/openshift/cluster-version-operator/vendor/k8s.io/apimachinery/pkg/util/runtime/runtime.go:76
/go/src/github.com/openshift/cluster-version-operator/vendor/k8s.io/apimachinery/pkg/util/runtime/runtime.go:65
/go/src/github.com/openshift/cluster-version-operator/vendor/k8s.io/apimachinery/pkg/util/runtime/runtime.go:51
/usr/local/go/src/runtime/asm_amd64.s:573
/usr/local/go/src/runtime/panic.go:502
/usr/local/go/src/runtime/chan.go:333
/go/src/github.com/openshift/cluster-version-operator/vendor/k8s.io/client-go/util/workqueue/delaying_queue.go:137
```
Use sync.Once to guarantee a single close.
Kubernetes-commit: d2f7eb5235a93556261c8947e7a87342aeeaee2b
The backoff value is baseDelay*2^<num-failures> in ItemExponentialFailureRateLimiter.When . But the comment is baseDelay*10^<num-failures>.
Kubernetes-commit: c1fa760b75970fbd0c142971f1142754cb4ea3fc
