-
Notifications
You must be signed in to change notification settings - Fork 1.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
Add run termination controls to ui #1039
Add run termination controls to ui #1039
Conversation
Fixes #413 |
/test kubeflow-pipeline-e2e-test |
frontend/src/lib/Buttons.ts
Outdated
callback: (_: string[], success: boolean) => void): void { | ||
this._dialogActionHandler( | ||
ids, | ||
'Do you want to terminate this run? This action cannot be undone.', |
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.
I think this text can use some more elaboration. Maybe it should indicate what happens to running pods.
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.
How about:
Do you want to terminate this run? This action cannot be undone. The run is terminated by setting the activeDeadlineSeconds of the Argo workflow to 0. This terminates the workflow without deleting the pods.
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.
The run is terminated by setting the activeDeadlineSeconds of the Argo workflow to 0. This terminates the workflow without deleting the pods.
I'd say that's too much implementation info.
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.
How about
"Do you want to terminate this run?
All the running tasks will be terminated."
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.
I agree, there's no need to surface Argo here.
Do running tasks (pods) really terminate? Argo just doesn't schedule any more pods AFAIR.
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, the pods are terminated:
https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/#job-termination-and-cleanup
Do you want to terminate this run? This action cannot be undone. This will terminate any running pods, but they will not be deleted.
?
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.
Is Argo using a k8s job? I didn't think so. Did you verify that any long running pods are killed?
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.
Pods are terminated before they complete, not after
frontend/src/pages/Status.tsx
Outdated
case NodePhase.UNKNOWN: | ||
return false; | ||
default: | ||
return false; | ||
} | ||
} | ||
|
||
export function statusToBgColor(status?: NodePhase): string { | ||
export function statusToBgColor(status?: NodePhase, errorMessage?: string): string { |
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.
nit: Would it be cleaner if the status is reconciled with the error message before being passed here, rather than have this function do the reconciliation?
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.
Neither is great because what we're doing isn't great. I think this approach has a slightly lower chance of mistakes (e.g. failing to provide error / failing to call disambiguation function) being made because the extra param serves as a reminder (i think i can give it a better name), but I agree that it's not ideal and am willing to have the disambiguation function called outside of these functions
@@ -49,6 +49,10 @@ export abstract class Page<P, S> extends React.Component<P & PageProps, S> { | |||
this._isMounted = false; | |||
} | |||
|
|||
public componentDidMount(): void { |
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.
Curious why this is needed, doesn't it mean cleanup isn't done properly somewhere?
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, the banner sticks when navigating from the RunDetails
page back to the experiment/run list page using the toolbar nav arrow. We could pass the clearBanner
function to the Toolbar
and call it when the arrow is clicked, but is that better?
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.
Shouldn't the unmount method on RunDetails clear the banner in that case?
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, that also fixes it and I'll add it there.
Any reason to remove this code though?
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.
clearBanner is already called in the unmount method right? I was wondering why that doesn't take care of it.
It's just a little confusing to me to see two initialization code blocks (constructor and componentDidMount), I think it should be avoided, but it's not a strong reason.
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.
Yeah, I'm not sure why it doesn't take care of it
@@ -374,6 +390,7 @@ class RunDetails extends Page<RunDetailsProps, RunDetailsState> { | |||
buttons.restore(idGetter, true, () => this.refresh()) : | |||
buttons.archive(idGetter, true, () => this.refresh()); | |||
actions.splice(2, 1, newButton); |
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.
Is this index still correct now that we have one more button before Archive/Restore?
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.
Good call. No, it was removing the refresh button.
Do we need a refresh button though now that we have autorefresh? it would seem not
/test kubeflow-pipeline-e2e-test |
3 similar comments
/test kubeflow-pipeline-e2e-test |
/test kubeflow-pipeline-e2e-test |
/test kubeflow-pipeline-e2e-test |
b07f28e
to
3c7f648
Compare
/test kubeflow-pipeline-e2e-test |
1 similar comment
/test kubeflow-pipeline-e2e-test |
/test kubeflow-pipeline-e2e-test |
2 similar comments
/test kubeflow-pipeline-e2e-test |
/test kubeflow-pipeline-e2e-test |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: IronPan The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
* handle pipelineloop status When using `embedded-status: minimal`, the nested pipelineloop status is missing. Add logic in persistence agent to retrieve runs and taskruns status for nested pipelineloop. Signed-off-by: Yihong Wang <yh.wang@ibm.com> * Add an arg to specify the kinds Use an arg to specify the kinds which contain childReferences information. Persistence agent uses this list to retrieve taskrun/run status and embedded them into the final PipelineRun yaml. Signed-off-by: Yihong Wang <yh.wang@ibm.com> Signed-off-by: Yihong Wang <yh.wang@ibm.com>
Adds a
Terminate
button to the run details page, allowing users to request that the pipeline execution be stopped:This action is irreversible and the user is asked to confirm before the command is issued:
Afterward, the
Terminate
button is disabled, and a warning banner is shown explaining that the run was terminated. The step that was executing when the pipeline terminated gets a special status icon indicating that it was stopped:If there were multiple steps running when the pipeline was terminated, each will show the stopped icon:
The list pages will show terminated runs as
Failed
, and will not indicate that they are terminated due to #1040This change is