Prevent deployer pod creation conflicts#8588
Conversation
|
LGTM |
|
Does this handle cases where the controller's pod cache is not populated yet (like on startup)? What about cases where the cache has not yet observed a deletion of the pod? |
This controller doesn't use a pod cache, so everything is responsive to updates to the RC. No caching issues to worry about. |
|
[test] |
|
Can you create a soak extended test that proves this fixes the issue? We don't have to merge it, but I want to see code and a run that proves it's not regressing |
|
[test] |
Take advantage of a single-controller assumption by checking for the existence of deployer pods before trying to create new ones. This allows the controller to progress the phase of the deployment without incurring a resource conflict during create under most circumstances- a behavior which can result in poor interactions with the quota system which will charge quota for the conflicting pod.
ironcladlou
force-pushed
the
prevent-deployer-pod-conflicts
branch
from
50a101e to
552aa83
Compare
|
Evaluated for origin test up to 552aa83 |
|
continuous-integration/openshift-jenkins/test FAILURE (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/3185/) |
|
Waiting for the rc1 fix to merge |
|
Approved as per earlier decision today, [merge] On Thu, Apr 21, 2016 at 6:10 PM, OpenShift Bot notifications@github.com
|
|
#7429 flake [merge] |
|
#7429 flake again. [merge] |
|
It's not the same flake, I think our merges are blanks:( |
|
[merge] |
1 similar comment
|
[merge] |
|
continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_origin/5664/) (Image: devenv-rhel7_4016) |
|
Failed because of image import retry on a method I didn't wrap: [merge] On Fri, Apr 22, 2016 at 3:45 PM, OpenShift Bot notifications@github.com
|
|
Evaluated for origin merge up to 552aa83 |
5 participants
Take advantage of a single-controller assumption by checking for the
existence of deployer pods before trying to create new ones. This allows
the controller to progress the phase of the deployment without incurring
a resource conflict during create under most circumstances- a behavior
which can result in poor interactions with the quota system which will
charge quota for the conflicting pod.