Reuse existing executionClusterLabel value during relaunch #minor#873
Reuse existing executionClusterLabel value during relaunch #minor#873va6996 wants to merge 6 commits intoflyteorg:masterfrom
Conversation
|
Thank you for opening this pull request! 🙌 These tips will help get your PR across the finish line:
|
Signed-off-by: va6996 <vinayakagarwal6996@gmail.com>
Signed-off-by: va6996 <vinayakagarwal6996@gmail.com>
|
Hey @va6996, sorry for the delay in reviewing your PR; it looks good but there is a minor merge conflict. But its approved now so we can merge it once the conflict is resolved 👍 |
|
@jsonporter could you take a look again? the review got dismissed |
|
@va6996 , can you add a screenshot of the launch form with the |
Hi @eapolinario this change did not modify the UI. The cluster details were passed through, based on the current label. This fixed the immediate issue where if a user relaunched a workflow (originally in a custom cluster), the workflow got launched in a different (default) cluster. |
| LaunchInterruptibleInputRef, | ||
| LaunchOverwriteCacheInputRef, | ||
| LaunchRoleInputRef, | ||
| LaunchRoleInputRef, LaunchExecutionClusterLabelInputRef, |
There was a problem hiding this comment.
nit: move to separate line.
|
@FrankFlitton , can you take a look? |
|
@eapolinario @FrankFlitton updated based on the comments |
TL;DR
Support execution cluster labels in flyteconsole. Additionally, reuse existing executionClusterLabel (if available from workflow execution) value for relaunching workflow/tasks
Type
Are all requirements met?
Complete description
When a user specifies the execution cluster label for a single execution, that information is lost when the user clicks relaunch. This change automatically sets the execution cluster to the value set in the original workflow. Subsequent changes to allow specifying the cluster label via UI can be taken up later.
Tracking Issue
NA
Follow-up issue
NA