Bug 1507119 - oc apply and replace terminate upgrades if a resource update is contentious
Summary: oc apply and replace terminate upgrades if a resource update is contentious
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Cluster Version Operator
Version: 3.6.1
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 3.6.z
Assignee: Stephen Cuppett
QA Contact: liujia
Depends On:
TreeView+ depends on / blocked
Reported: 2017-10-27 18:22 UTC by Justin Pierce
Modified: 2018-09-26 04:11 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Retries have been added to shared-resource-viewer update logic avoiding problems with object contention.
Clone Of:
Last Closed: 2018-09-26 04:10:45 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:2654 None None None 2018-09-26 04:11:05 UTC

Description Justin Pierce 2017-10-27 18:22:48 UTC
Description of problem:

Errors like:
TASK [Fixup shared-resource-viewer role] ***************************************
Friday 27 October 2017  18:05:27 +0000 (0:00:00.494)       0:17:25.352 ******** 
fatal: [engint-master-81c2f]: FAILED! => {"changed": false, "failed": true, "msg": {"cmd": "/usr/bin/oc replace -f /tmp/shared_resource_viewer_role.yaml -n openshift", "results": {}, "returncode": 1, "stderr": "Error from server (Conflict): error when replacing \"/tmp/shared_resource_viewer_role.yaml\": Operation cannot be fulfilled on name.authorization.openshift.io \"shared-resource-viewer\": the object has been modified; please apply your changes to the latest version and try again\n", "stdout": ""}}
changed: [engint-master-b8539]
changed: [engint-master-39a9e]

are inevitable in OpenShift for some objects. If this error is encountered, operations like replace & apply could be automatically retried instead of terminating the upgrade. 


Comment 2 Luiz Carvalho 2017-12-06 15:32:42 UTC
Also have this issue. Re-running the upgrade plugin caused the upgrade to complete successfully. (3.5 -> 3.6)

Comment 3 Scott Dodson 2018-01-23 21:58:31 UTC

This seems like something that's been fixed in the client recently, does that seem correct?


Comment 4 Mo 2018-01-24 22:38:14 UTC
Not that I am aware of.  Since this step only applies from 3.5 to 3.6, I suggested adding 10 retries via ansible.

Comment 7 liujia 2018-09-14 01:10:32 UTC
1. Install ocp v3.
2. Upgrade ocp to v3.

Upgrade succeed. Can not re-produce on v3.

Comment 8 liujia 2018-09-14 01:27:01 UTC
Checked the pr9733, I think this enhancement can help improve the process instead of re-run upgrade because failure of operations like replace & apply are inevitable.Adding some retried is necessary. 

So QE will check the pr and verify upgrade works well on latest v3.6

Comment 9 liujia 2018-09-14 03:25:32 UTC

Upgrade ovp v3. to v3. succeed.
Upgrade ocp v3. to v3. succeed.

Comment 11 errata-xmlrpc 2018-09-26 04:10:45 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.