Syncing latest changes from upstream devel for ceph-csi

[df-build-team]

PR containing the latest commits from upstream devel branch

[nixpanic]

/approve
/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: df-build-team, nixpanic

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [nixpanic]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[nixpanic]

/cherry-pick release-4.19 release-4.18 release-4.17

[openshift-cherrypick-robot]

@nixpanic: once the present PR merges, I will cherry-pick it on top of release-4.19 in a new PR and assign it to you.

In response to this:

/cherry-pick release-4.19 release-4.18 release-4.17

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[openshift-cherrypick-robot]

@nixpanic: new pull request created: #471

In response to this:

/cherry-pick release-4.19 release-4.18 release-4.17

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[Nikhil-Ladha]

/cherry-pick release-4.19 release-4.18 release-4.17

Why are we cherry-picking these commits to release branches?
The release branches get sync PRs when the DS build passes the CI, we should never be doing this! If we do so, we are basically merging untested commits to release branches.

Also, why are we backporting to older branches too? Those are already released and we should only cherry-pick the bug fixes to them not the master sync commits.

[nixpanic]

/cherry-pick release-4.19 release-4.18 release-4.17

Why are we cherry-picking these commits to release branches? The release branches get sync PRs when the DS build passes the CI, we should never be doing this! If we do so, we are basically merging untested commits to release branches.

Also, why are we backporting to older branches too? Those are already released and we should only cherry-pick the bug fixes to them not the master sync commits.

@Nikhil-Ladha , in this case, the PR only contains 2 commits that address a CVE. We need to get them included in the branches where fixes for the CVE were requested. Some testing is done with GitHub actions, intended to prevent issues and regressions.

[Nikhil-Ladha]

@Nikhil-Ladha , in this case, the PR only contains 2 commits that address a CVE. We need to get them included in the branches where fixes for the CVE were requested. Some testing is done with GitHub actions, intended to prevent issues and regressions.

That's fine, but 4.19 is an active development branch and we shouldn't be cherry-picking to it, unless the feature freeze has happened. The CVE fix would have ultimately gone into the branch in sometime when the stable build happens.

[nixpanic]

@Nikhil-Ladha , in this case, the PR only contains 2 commits that address a CVE. We need to get them included in the branches where fixes for the CVE were requested. Some testing is done with GitHub actions, intended to prevent issues and regressions.

That's fine, but 4.19 is an active development branch and we shouldn't be cherry-picking to it, unless the feature freeze has happened. The CVE fix would have ultimately gone into the branch in sometime when the stable build happens.

It is still required that fixes land in release-4.19 before release-4.18 to prevent potential misses. Eventual consistency is nice, but in this case there needs to be a guaranteed order (backported to release-4.18 in #472).

If this caused a problem of some kind for the automation of sync-PRs, I'm sorry! Hopefully you understand my intentions too 😃