-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
deployment controller: cancel deployers on new cancelled deployments #8418
deployment controller: cancel deployers on new cancelled deployments #8418
Conversation
[test] |
Deployer pods may stay around due to an unavailable node and get scheduled after a cancelled deployment has been transitioned from New to Failed.
@@ -62,7 +62,7 @@ func LabelForDeployment(deployment *api.ReplicationController) string { | |||
|
|||
// LabelForDeploymentConfig builds a string identifier for a DeploymentConfig. | |||
func LabelForDeploymentConfig(config *deployapi.DeploymentConfig) string { | |||
return fmt.Sprintf("%s/%s:%d", config.Namespace, config.Name, config.Status.LatestVersion) | |||
return fmt.Sprintf("%s/%s", config.Namespace, config.Name) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was this change intentional?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is confusing since we already name deployments after their version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this going to cause backwards compatibility issues?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why? AFAIK we use it only for logging
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, my grep-fuu failed me.
[test] On Fri, Apr 8, 2016 at 8:10 AM, OpenShift Bot [email protected]
|
[test] On Fri, Apr 8, 2016 at 10:55 AM, OpenShift Bot [email protected]
|
LGTM once #8418 (comment) is answered |
Can we spawn a follow up to track the bigger implications of this (in the On Fri, Apr 8, 2016 at 11:39 AM, Dan Mace [email protected] wrote:
|
[test] On Fri, Apr 8, 2016 at 1:12 PM, OpenShift Bot [email protected]
|
@soltysh has the failure for pullthrough On Apr 8, 2016, at 3:50 PM, OpenShift Bot [email protected] wrote: continuous-integration/openshift-jenkins/test FAILURE ( — |
[test] |
Evaluated for origin test up to f444ceb |
continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/2870/) |
Approved [merge] |
continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_origin/5555/) (Image: devenv-rhel7_3946) |
#7429 flake re[merge] |
Evaluated for origin merge up to f444ceb |
Deployer pods may stay around due to an unavailable node and get scheduled
after a cancelled deployment has been transitioned from New to Failed.
Found out in #8403
@pweil- @smarterclayton @ironcladlou