FR: Pipelines UI - Dag tasks should also show the task name

[strangemonad-faire]

Currently the pretty Dag visualization just displays the template name. In a dag with multiple invocations of the same template (e.g. a workflow that has multiple sql queries) you don't get enough information.

Suggestion 1)

======================
[task-name]
[template-name]

======================

Suggestion 2) (just match the workflow yaml)

======================
name: [task-name]
template: [template-name]

======================

[strangemonad-faire]

To be clear, this is when viewing pipelines that have ben uploaded (the Pipelines tab). A run / scheduled workflow has the opposite issue where the name is displayed but the type of task (template name) isn't displayed

[rileyjbauer]

Suggestion 2 seems pretty reasonable to me. We've discussed which of task/template is more useful in the past, and it does seem arguable that they are both useful to be shown.

@ajayalfred what do you think of these suggestions?

[strangemonad-faire]

@rileyjbauer I do like option 2 (in both the '#pipelines/details' and '#runs/details' view), bonus points for nicely rendering key-values in the ui that match the yaml.

There are 2 potential issues with #2

1. is line length. I'm already hitting some template and task names that are truncated in the current rendering.
2. I don't think is inherent to this change but if you're hand coding a workflow yaml (or viewing a '#pipelines/details/' Source tab), we talk about dags, tasks and templates. In on the other hand you're using the python dsl, we're talking about pipelines and ops (even though it renders down to a workflow yaml file). Option 1 was a way to use a bold title / italic subtitle to not make the discrepancy in wording so obvious.

As I move more towards making things components, I think of the task's template as the task's "type" instantiated with the task's specific parameters so seeing both those values together as much as possible would be really helpful when just visually scanning

[ajayalfred]

I like suggestion #2 as well. The length of the label and string is an obvious challenge to fit in the node. While there can be some clever way of designing around that – I'm curious to know if we went with suggestion #1, would users implicitly understand bold is for name and italics is for template?

[Ark-kun]

Suggestion 2) (use task id) is not a good idea. Task id is implementation detail generated by the compiler. It can be changed to opaque hash string in future. The task ID is not human-readable and has technical limitations.

What we can do is to make the UX check the template annotation for the display name and use that if it's available.

This issue seems to be a duplicate of #1378

The proposal there would let the pipeline author specify arbitrary display name for every task:
my_task = my_op(...).add_pod_annotation('kubeflow.org/pipelines/task_display_name', 'My custom name')
or my_task = my_op(...).set_custom_display_name('My custom name')

[rileyjbauer]

@Ark-kun to confirm, your suggestion would be to use the display name if provided and otherwise fallback to the template?

[MinhManPham]

Hi @Ark-kun , I am using this script to custom the name of my task, I got this issue:ˇ
This step is in Error state with this message: task 'viewability-predictor-pipeline-zz4qj.training-2' errored: Pod "viewability-predictor-pipeline-zz4qj-1717721269" is invalid: metadata.annotations: Invalid value: "kubeflow.org/pipelines/task_display_name": a qualified name must consist of alphanumeric characters, '-', '_' or '.', and must start and end with an alphanumeric character (e.g. 'MyName', or 'my.name', or '123-abc', regex used for validation is '([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9]') with an optional DNS subdomain prefix and '/' (e.g. 'example.com/MyName')