The build controller was susceptible to incorrectly failing builds when time was not synchronised accurately between multiple masters. The controller logic has been improved to not depend on time synchronisation.

Description of problem:
After manually triggering a build by using POST /oapi/v1/namespaces/$NAMESPACE/buildconfigs/$NAME/instantiate, Build fails with "The pod for this build already exists and is older than the build."
Version-Release number of selected component (if applicable):
OpenShift Master:
v3.7.23
Kubernetes Master:
v1.7.6+a08f5eeb6
How reproducible:
This appears to happen randomly at about 10% of time.
Steps to Reproduce:
1. Create BuildConfig object
2. POST /oapi/v1/namespaces/$NAMESPACE/buildconfigs/$NAME/instantiate
Actual results:
Build is started and completed successfully.
Expected results:
Build fails with "The pod for this build already exists and is older than the build."
Additional info:
Not sure if relevant, but this cluster has two namespaces, each of which will have Pods of the same name. This shouldn't matter though because they are in different namespaces.

this is likely caused by the lastversion sequence in your buildconfig getting reset (perhaps you previously had a buildconfig w/ the same name and deleted it but the build pods were not deleted?)
Did you actually check if said pod does already exist? If so, where did it come from? when was it created, etcd?

I have not deleted any BuildConfig objects.
The pod does exist. I'm not sure how it was created. The information seem misleading:
BUILD:
osbs-test-hamburger-doc-distscope-restricted-au-db9f4-2
Status: The pod for this build already exists and is older than the build.
Started: Feb 21, 2018 6:52:03 AM
Duration: 0 seconds
POD:
osbs-test-hamburger-doc-distscope-restricted-au-db9f4-2-build
Status: Completed, ran for 51 seconds Build:
Build: osbs-test-hamburger-doc-distscope-restricted-au-db9f4-2
State: Terminated at Feb 21, 2018 6:52:52 AM (Completed)
The logs for the pod, which would help me determine what created it, are missing.
Note the build attribute on the pod object. It actually links to the correct build, but at the same time, the build states that a pod already exists.
Also note the timestamps. It looks like the Build and Pod objects were created pretty much at the same time.

It looks like the masters on this cluster are not synced to NTP and there is a few seconds' drift between them. Please fix up the clocks, see if the problem recurs, then update the bug with your findings. Thanks.

other possible causes are that the build pod really does exist from a prior attempt to build and the build sequence number has been reset in the buildconfig, or build objects are being created directly w/ old sequence numbers.

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.
https://access.redhat.com/errata/RHBA-2018:1816

Note

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