RecordMetrics() grabs a mutex and calls recordCancelMetric(), which wants to
grab the same mutex. Go mutexes are not recursive, so recordCancelMetric
blocks forever.
recordCancelMetric should not grab the mutex, it can be sure that the
caller did it already.
- Needed to start the http server outside of pkg/metric
- We needed this because we want to add other endpoints to the server
Signed-off-by: Grant Griffiths <ggriffiths@purestorage.com>
This patch adds two new parameters `retryIntervalStart & retryIntervalMax`
which can be configured to adjust the ratelimiters of snapshotqueue and contentqueue
in the controller.
Signed-off-by: Humble Chirammal <hchiramm@redhat.com>
```release-note
`retry-interval-start` and `retry-interval-max` arguments are added to common-controller
which controls retry interval of failed volume snapshot creation and deletion.
These values set the ratelimiter for snapshot and content queues.
```
Signed-off-by: Humble Chirammal <hchiramm@redhat.com>
Two new timeout values ( retryIntervalStart & retryIntervalMax )
have been added to set the ratelimiter for volumesnapshotcontent queue.
Fix# https://github.com/kubernetes-csi/external-snapshotter/issues/463
Signed-off-by: Humble Chirammal <hchiramm@redhat.com>
```release-note
`retry-interval-start` and `retry-interval-max` arguments are added to csi-snapshotter sidecar which controls retry interval of failed volume snapshot creation and deletion. These values set the ratelimiter for volumesnapshotcontent queue.
```
Signed-off-by: Humble Chirammal <hchiramm@redhat.com>
The error returned from CreateSnapshot was overwritten by the call to
removeAnnVolumeSnapshotBeingCreated. Retain the error through variable
shadowing so that it can be propagated and reported upwards the call
stack.
We also improve the error line by dropping an unnecessary comma and
dequoting the error string (since we already employ a colon separator).
ReadyToUse in Snapshot will be updated based on ReadyToUse in Content.
ReadytoUse in Snapshot will also be updated when caller indicates it should
be changed to false when an error occurrs.
https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/177-volume-snapshot/tighten-validation-webhook-crd.md
1. Ratcheting validation webhook server image
2. Controller labels invalid objects
3. Unit tests for webhook
4. Deployment README and example deployment method with certs
5. Update top-level README
Racheting validation:
1. webhook is strict on create
2. webhook is strict on updates where the existing object passes strict validation
3. webhook is relaxed on updates where the existing object fails strict validation (allows finalizer removal, status update, deletion, etc)
Additionally the validating wehook server will perform immutability
checks on scenario 2 above.
