test: retry rollout latest on update conflicts

[0xmichalis]

Fixes #11477

[test]

[0xmichalis]

@mfojtik

[0xmichalis]

#11094 [test]

[0xmichalis]

[test]

[mfojtik]

[test]

[openshift-bot]

Evaluated for origin test up to ab40017

[openshift-bot]

continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/10827/) (Base Commit: c3fc160)

[0xmichalis]

@mfojtik mind tagging?

[mfojtik]

@Kargakis why are we not protecting from the conflicts in oc rollout latest code? as an end-user I want to rollout and don't want to retry because something updated my config.

[0xmichalis]

Not always true. Most update conflicts happen due to the dc controller
updating the status of the deployment config. So someone could argue that
they would want to retry in such a case.

On Mon, Oct 31, 2016 at 2:54 PM, Michal Fojtik notifications@github.com
wrote:

@Kargakis https://github.com/kargakis why are we not protecting from
the conflicts in oc rollout latest code? as an end-user I want to rollout
and don't want to retry because something updated my config.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11482 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADuFf5p4x93gXB5VrQiEbg2k-_0L7O8Hks5q5fL4gaJpZM4KdA15
.

[mfojtik]

@Kargakis is there a case when they don't want to retry? end users don't know about controller updating the status and I can argue that don't care when they just created the DC.

[0xmichalis]

@Kargakis is there a case when they don't want to retry? end users don't know about controller updating the status and I can argue that don't care when they just created the DC.

I can't think of any.

[mfojtik]

@Kargakis i'm ok with this to fix flaky tests for now but we should add TODO and create issue to add retrying into rollout latest (in upstream). WDYT?

[0xmichalis]

@mfojtik there is no rollout latest upstream. I have proposed somewhere to use GuaranteedUpdate in instantiate (similar to how the upstream rollback REST uses GuaranteedUpdate for rollbacks) but we really need to think if it's 100% correct to do so.

[0xmichalis]

@mfojtik merge this?

[mfojtik]

[merge]

[0xmichalis]

#12155 [merge]

[mfojtik]

flake: #11004

[merge]

[0xmichalis]

#11004 and #12072 [merge]

[0xmichalis]

flake is #12157

[0xmichalis]

[merge]

[openshift-bot]

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/10827/) (Image: devenv-rhel7_5515)

[0xmichalis]

#8571 [merge]

[openshift-bot]

Evaluated for origin merge up to ab40017