[release-4.7] [release-4.8] Bug 1996132: Fix deployment update with retry option

[openshift-cherrypick-robot]

This is an automated cherry-pick of #1285

/assign sdodson

[openshift-ci]

@openshift-cherrypick-robot: Bugzilla bug 1982369 has been cloned as Bugzilla bug 1996132. Retitling PR to link against new bug.
/retitle [release-4.7] [release-4.8] Bug 1996132: Fix deployment update with retry option

In response to this:

[release-4.7] [release-4.8] Bug 1982369: Fix deployment update with retry option

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/test-infra repository.

[openshift-ci]

@openshift-cherrypick-robot: This pull request references Bugzilla bug 1996132, which is invalid:

• expected dependent Bugzilla bug 1982369 to be in one of the following states: VERIFIED, RELEASE_PENDING, CLOSED (ERRATA), CLOSED (CURRENTRELEASE), but it is ASSIGNED instead

Comment /bugzilla refresh to re-evaluate validity if changes to the Bugzilla bug are made, or edit the title of this pull request to link to a different bug.

In response to this:

[release-4.7] [release-4.8] Bug 1996132: Fix deployment update with retry option

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/test-infra repository.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: openshift-cherrypick-robot
To complete the pull request process, please assign lilic after the PR has been reviewed.
You can assign the PR to them by writing /assign @lilic in a comment when ready.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[dgrisonnet]

Holding as I don't think we should backport this down to 4.7 since it will most likely not fix the issue. The retry loop is meant to only retry on conflicts but after investigating again with @slashpai we found out that to the apiserver, having an object being deleted does not count as a conflict. Only creation and updates count as conflicts.

We discussed this bug on slack with @sttts who suggested that we should look into fixing the object that causes the 422 Unprocessable Entity error rather than trying to re-create the resource as a whole. https://coreos.slack.com/archives/CB48XQ4KZ/p1628504884207800. That said it is still odd that the garbage collector doesn't wait for the resource to be deleted even so we have set DeleteOptions to DeletePropagationForeground and that blockOwnerDeletion is set on the dependent objects. That might be something we want to look further into.

Feel free to remove the hold if you think otherwise, but in my opinion, this change won't fix the issue.

/hold

[sdodson]

Ok, I'll go make sure that the bugs I marked as VERIFIED based on @simonpasquier evaluation of CI upgrade jobs are not VERIFIED.

[simonpasquier]

/close

we're only backporting the fix up to 4.8.

[openshift-ci]

@simonpasquier: Closed this PR.

In response to this:

/close

we're only backporting the fix up to 4.8.

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/test-infra repository.