Bug 1329138

Summary:	Any dc has the error: the object has been modified
Product:	OKD	Reporter:	XiaochuanWang <xiaocwan>
Component:	Deployments	Assignee:	Michail Kargakis <mkargaki>
Status:	CLOSED CURRENTRELEASE	QA Contact:	zhou ying <yinzhou>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	3.x	CC:	aos-bugs, erich, misalunk, mkargaki, nbhatt, sspeiche
Target Milestone:	---
Target Release:	3.x
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-09-19 13:50:13 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description XiaochuanWang 2016-04-21 09:39:52 UTC

Description of problem:
Create new app and then describe all dc no matter pods are succeed or not. Event will show "Cannot update deployment xiaocwan-t/database-1 status to Pending: replicationcontrollers "database-1" cannot be updated: the object has been modified; please apply your changes to the latest version and try again"

Version-Release number of selected component (if applicable):
oc v1.1.6-169-gde5b801
openshift v1.1.6-169-gde5b801
kubernetes v1.2.0-36-g4a3f9c5
etcd 2.2.5

How reproducible:
Always

Steps to Reproduce:
1. Create a new app
 e.g. `oc run hello --image=openshift/hello-openshift`
 e.g. `oc new-app -f https://raw.githubusercontent.com/openshift/origin/master/examples/sample-app/application-template-stibuild.json`
2. Describe dc after dc succeed 
3. Check event

Actual results:
All dc have the error like: Cannot update deployment xiaocwan-t/database-1 status to Pending: replicationcontrollers "database-1" cannot be updated: the object has been modified; please apply your changes to the latest version and try again

Expected results:
This error should not occur

Additional info:

Comment 1 Michail Kargakis 2016-04-21 12:42:53 UTC

Update conflicts on the deployment are natural because they are being processed by three different controllers (rc manager, deployer pod controller, deployment controller). We moved emitting events from deployments (rcs) to deploymentconfigs and those events stay around (naturally) even after the deployment is reprocessed by our controllers. We should either stop emitting events on update conflicts or have follow-up events on successful processing. Marking this for upcoming release for now.

Comment 2 Wei Sun 2016-05-09 03:01:09 UTC

*** Bug 1333974 has been marked as a duplicate of this bug. ***

Comment 3 openshift-github-bot 2016-05-11 01:40:35 UTC

Commit pushed to master at https://github.com/openshift/origin

https://github.com/openshift/origin/commit/68c70739ef5581c0fc5075adbe0030ab0623a192
Bug 1329138: stop emitting events on update conflicts

Update conflicts for deployments are pretty common since they are
handled by three different controllers (kube: rc manager, origin:
deployer pod controller, deployment controller) and their events
stay attached on deploymentconfigs which may confuse users ("My
deployment is running but I have this event over there talking about
an update conflict"). Since those errors are retried by the controller
there is no reason to emit events for them.

Comment 4 Michail Kargakis 2016-05-11 08:22:58 UTC

No more update conflict events on dcs

Comment 5 XiaochuanWang 2016-05-11 08:45:51 UTC

Tested on devenv-rhel7_4161 and it doesn't reproduced
Verified.
openshift v1.3.0-alpha.0-460-gd0a9ad9
kubernetes v1.3.0-alpha.1-331-g0522e63
etcd 2.3.0
oc v1.3.0-alpha.0-460-gd0a9ad9

Comment 13 Michail Kargakis 2017-07-03 09:33:23 UTC

No, it's not backported to 3.2 as far as I remember but the event is purely informational and not an actual problem so I am not sure whether a backport is warranted.