Hide Forgot
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:
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.
*** Bug 1333974 has been marked as a duplicate of this bug. ***
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.
No more update conflict events on dcs
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
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.