Automatic merge from submit-queue (batch tested with PRs 41775, 39678, 42629, 42524, 43028)
matchPredicate does not fit findByClaim()
matchPredicate has two args which are type of PV,and is not used in function findByClaim(),remove it
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue (batch tested with PRs 43373, 41780, 44141, 43914, 44180)
Updated comments according to the logic.
Updated comments according to the logic: it'll return empty string instead of nil if failed to match the regex.
Automatic merge from submit-queue
small code improvements and fix some typos
Signed-off-by: bruceauyeung <ouyang.qinhua@zte.com.cn>
**What this PR does / why we need it**:
1. eliminate unnecessary extra scale up limit calculation
2. eliminate unnecessary extra pods length computation
3. fix some typos
Automatic merge from submit-queue (batch tested with PRs 42961, 44042)
Allow swapping NotReady and Unschedulable Taints
Fix#43444
cc @kubernetes/sig-scheduling-pr-reviews @davidopp @aveshagarwal @mdshuai
For cherrypick @ethernetdan
Automatic merge from submit-queue (batch tested with PRs 43963, 43965)
Update deployment retries to a saner count
It seems that the current retries sum up to no more than 0.2s so some transient errors may drop deployments out of the queue.
Automatic merge from submit-queue (batch tested with PRs 43963, 43965)
Wait for clean old RSs statuses in the middle of Recreate rollouts
After https://github.com/kubernetes/kubernetes/pull/43508 got merged, we started returning ReplicaSets with no pods but with stale statuses back to the rollout functions. As a consequence, one of our e2e tests that checks if a Recreate Deployment runs pods from different versions, started flakying because the Deployment status may be incorrect. This change simply waits for the statuses to get cleaned up before proceeding with scaling up the new RS.
Fixes https://github.com/kubernetes/kubernetes/issues/43864
@kubernetes/sig-apps-bugs
Automatic merge from submit-queue (batch tested with PRs 44084, 42964)
Updated AddOrUpdateTolerationInPod to return bool only.
Updated AddOrUpdateTolerationInPod to return bool only, as there's no case to generate error (the error was used for annotation, it'll not return error after moving to field); and also update admission & daemonset accordingly.
Automatic merge from submit-queue (batch tested with PRs 43453, 42992)
make sure that the volume satisfies the requirements of the claim before binding
check if the volume requested by the claim satisfies the requirements of the claim before binding when
syncUnboundClaim and claim.Spec.VolumeName is not set, although the volume is asked by user
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue
Adding gnufied as reviewer for volume controller
I have helped review several PRs and made new
PRs to this area.
cc @childsb @saad-ali
check if the volume requested by the claim satisfies the requirements of the claim before binding when
syncUnboundClaim and claim.Spec.VolumeName is not set
Automatic merge from submit-queue
Make Constants Public so that They Can Be Used in an Ext. Provisioner
Out-of-tree external provisioners have the same purpose as in-tree provisioners. As external provisioners work with PV and PVC datastructures it's an advantage to import certain Kubernetes packages instead of copy-pasting the Kubernetes code.
That's why the constants are made public so that they can be used in an external provisioner.
@jsafrane @kubernetes/sig-storage-pr-reviews
```
NONE
```
Automatic merge from submit-queue
update pkg/controller/volume/OWNER to add appropriate approvers for both volume controllers
Update pkg/controller/volume approvers so that the attach/detach and binding controllers have approvers.
Automatic merge from submit-queue
Attach/detach controller: fix potential race in constructor
**What this PR does / why we need it**:
There is a potential race condition in the Attach/detach controller: The "constructor" first installs informer event handlers and then creates and initializes the other data structures. However there is no guarantee an event cannot arrive before the data structures required by the event handlers are ready. This may result in nil pointer derefernces and potential crashes (e.g. the nodeAdd method calls adc.actualStateOfWorld.SetNodeStatusUpdateNeeded even though the actualStateOfWorld might be still nil).
It should be enough just to move the event handlers installation at the end of the constructor function.
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue
fix createProvisionedPV result err judgenment bug
When ctrl.kubeClient.Core().PersistentVolumes().Create(volume) returns no err, and storeVolumeUpdate() fails, we save PV sucessfully ,but here err is not nil,we should not run the codes next in block if err != nil {} to delete the storage asset.
same in the deletion retries below
change the err names to make it clear
**Release note**:
```release-note
NONE
```
@jsafrane @saad-ali PTAL. Thanks
Automatic merge from submit-queue
Fix PVC Annotations
annDynamicallyProvisioned is added to PV, while PVC has annStorageProvisioner.
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue (batch tested with PRs 43429, 43416, 43312, 43141, 43421)
remove duplicated import
**What this PR does / why we need it**:
**Which issue this PR fixes**:
**Special notes for your reviewer**:
**Release note**:
```
NONE
```
Automatic merge from submit-queue (batch tested with PRs 43378, 43216, 43384, 43083, 43428)
Remove unused argument of 'groupJobsByParent' in cronjob controller
**What this PR does / why we need it**:
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #
**Special notes for your reviewer**:
**Release note**:
```release-note
```
When ctrl.kubeClient.Core().PersistentVolumes().Create(volume) returns no err, but storeVolumeUpdate() failed, we save PV sucessfully ,but here err is not nil,
we should not run the codes next in block if err != nil {}
same in the deletion retries below
Automatic merge from submit-queue (batch tested with PRs 42522, 42545, 42556, 42006, 42631)
optimize the binding logic of bindClaimToVolume
extract var shouldSetBoundByController and do not need to judge volumename twice
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue
fix typos
**What this PR does / why we need it**:
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #
**Special notes for your reviewer**:
**Release note**:
```release-note
```
Automatic merge from submit-queue
small change to ControlleeExpectations result judgement
GetByKey() will never return err, so err != nil {} is redundant,remove it and remove the err return too
**Release note**:
```release-note
NONE
```
Out-of-tree external provisioners have the same purpose as in-tree provisioners. As external provisioners work with PV and PVC datastructures it's an advantage to import certain Kubernetes packages instead of copy-pasting the Kubernetes code.
That's why the constants are made public so that they can be used in an external provisioner.
Auto-generated via:
git grep -l [Ss]uccesfully | xargs sed -ri 's/([sS])uccesfully/\1uccessfully/g'
I noticed this when running kube-scheduler with --v4 and it is annoying.
Then manually reverted changed to the vendored bits.
Automatic merge from submit-queue (batch tested with PRs 43481, 43419, 42741, 43480)
controller: work around milliseconds skew in AddAfter
AddAfter is not requeueing precisely after the provided time and may
skew for some millieseconds. This is really important because controllers
don't relist often so a missed check because of ms difference is
essentially dropping the key. For example, in [1] the test requeues a
Deployment for a progress check after 10s[2] but the Deployment is synced
9ms earlier ending up in the controller not recognizing the Deployment as
failed thus dropping it from the queue w/o any error. The drop is fixed by
forcing the controller to resync the Deployment but we are going to resync
after the full duration.
@deads2k if you don't like this I am going to handle this on a case by case basis
[1] https://github.com/kubernetes/kubernetes/issues/39785#issuecomment-279959133
[2] c48b2cab0f/test/e2e/deployment.go (L1122)
Automatic merge from submit-queue
Rate limit HPA controller to sync period
Since the HPA controller pulls information from an external source that
makes no guarantees about consistency, it's possible for the HPA
to get into an infinite update loop -- if the metrics change with
every query, the HPA controller will run it's normal reconcilation,
post a status update, see that status update itself, fetch new metrics,
and if those metrics are different, post another status update, and
repeat. This can lead to continuously updating a single HPA.
By rate-limiting each HPA to once per sync interval, we prevent this
from happening.
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue
Deflake TestSyncDeploymentDeletionRace
**What this PR does / why we need it**:
The cache was sometimes catching up while we were testing the case
where the cache is not yet caught up.
Before this fix, I could reproduce the failure with the following
command. After the fix, it passes.
```
go test -count 100000 -run TestSyncDeploymentDeletionRace
```
I checked the other controllers, and they all were already not starting informers for the deletion race test. I also checked that the deletion race tests for other controllers all pass with `-count 100000`.
**Which issue this PR fixes**:
Fixes#43390
**Special notes for your reviewer**:
**Release note**:
```release-note
NONE
```
The cache was sometimes catching up while we were testing the case
where the cache is not yet caught up.
Before this fix, I could reproduce the failure with the following
command. After the fix, it passes.
```
go test -count 100000 -run TestSyncDeploymentDeletionRace
```
