Chore: investigate the effort for nested dashboard links.

[misohu]

Why it needs to get done

We want to investigate effort for this task https://github.com/canonical/kubeflow-dashboard-operator/issues/197

What needs to get done

Investigate following questions:

What effort is needed? Do we need to update multiple charms or just kfp? Do we need to update the library version from 0 to 1? Will the change break the behavior in 1.8?

When is the task considered done

Above questions are answered.

[syncronize-issues-to-jira[bot]]

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/KF-5817.

This message was autogenerated

[misohu]

Context: The issue at hand is that upstream now utilizes nested dashboard links, while the current charm’s dashboard library is not designed to accommodate this. Upstream introduced a new item in the dashboard configmap links with the following changes:

• New type: section
• An items field that can hold other sidebar links. Other links here don’t have the icon field.

Currently, we use the DashboardLink class to represent elements in the sidebar, considering only a single layer with no nested links. Charms intending to be present in the sidebar send a stringified DashboardLink object through a relation to the Dashboard charm.

1. Simple Working Solution:

• Add an items field to the DashboardLink class.
• Note: The root link of the section has different arguments than the class. By simply adding the type section and the items argument, the class becomes somewhat "messy," with many unused arguments.
• Potential improvement: Create a base class (BaseDashboardLink) and use inheritance to create specific ones like DashboardLink and NestedDashboardLink.

Considerations:

• Items in a section may contain links from different charms. Currently, they do not.
• Presently, only KFP uses one nested dashboard link for all its links. If upstream combines links from different components, this becomes complex with no easy solution.
• Sorting nested sublinks within a group poses a challenge.

2. Complicated Solution for Edge Case with Combined Nested Links:

• Send DashboardLinks in a 1D array but add a special argument called section. If a DashboardLink has the section specified, the Kubeflow dashboard will group it into the section nested link.
• Question: Where to store metadata about the section’s root link (e.g., text and icon)? One potential solution is to include these in the dashboard config, though it may feel unconventional.

Example

# Charm 1
[DashboardLink(text="linkA"), DashboardLink(text="linkB", section="group1"), DashboardLink(text="linkC", section="group1")]

# Charm 2
[DashboardLink(text="linkD", section="group1")]

# Result
# - LinkA
# - Group1
# - - LinkB
# - - LinkC
# - - LinkD

3. Ignoring the Nested Links:

• Simply removing the custom dashboard link library is an option, albeit not ideal.

Sorting problem:

• Currently, we sort sidebar links by specifying a list of texts in the desired order in the dashboard config.
• To sort nested links, we could: Create a config option for each link group that accepts a list of ordered texts from the links. E.g., menu-link-order-pipelines: ["L1", "L2"].

Concerns

• What if upstream introduces combined nested links from different charms (as mentioned above)?
• What if upstream introduces more nested groups?

[misohu]

We had discussion about this problem on tech topics. These are the conclusions:

• We don't need to sort nested list (just use the code for it in the parent charm).
• We will talk to product if we can skip this upstream change
• We will refactor the list of links coming from pipelines to reflect changes in link and text section
• In case we have to implement it we will go with option 1 relying on the fact that there is little to no chance that upstream may combine links from different charms into groups.
• If we dont have to do the nested links we will use same text for kfp links as if they were nested + we will use icons from 1.8