-
Notifications
You must be signed in to change notification settings - Fork 1
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
feat: add user-driven sidebar links via config #119
feat: add user-driven sidebar links via config #119
Conversation
Adds: * KubeflowDashboardSidebarRequirer * KubeflowDashboardSidebarProvider * SidebarItem * associated tests
Used as a helper in unit tests
This change delays the computation of the k8s context until it is needed, instead of in __init__. It does not change the outward function of the charm. This change was implemented because in future, the sidebar links will be obtained from a relation and this should not be done in __init__.
previously, the Provider lib had a bug that would return only the last relation's data, not the entire set of data. This fixes that bug.
Includes unit tests
This adds the feature to get_sidebar_items to, when executed during a relation-broken event for this relation, omit the relation data for the breaking app (the app leaving the relation). For context, see https://chat.charmhub.io/charmhub/pl/ Possibly controversially, this feature uses the Juju environment variables to determine what event type is being executed. This is to avoid having to pass the `BoundEvent` object to every `get_sidebar_items()` call, and to keep this hack entirely in the relation library so the charm does not need to know about it.
Previously, the links portion of the kubeflow dashboard configmap was incorrectly rendering only the menulinks, not all links.
Removes tests for previously defined static links.
When refactoring the template, the links were changed by mistake. This reverts those changes.
9e546bb
to
9e07d02
Compare
This is a precursor step that makes the _context generation more extendable for other sources of links.
This adds a config option additional-sidebar-links which accepts a YAML or JSON formatted input defining additional sidebar links. These are combined with the relation-driven sidebar links.
33c6ee0
to
0cb4218
Compare
…branch' into kf-3664-add-user-defined-sidebar-links # Conflicts: # src/charm.py # tests/integration/sidebar_requirer_tester_charm/src/charm.py # tests/integration/test_charm.py # tests/unit/test_operator.py # tests/unit/test_sidebar_lib.py
a44e118
to
0ac3a17
Compare
just to confirm, did not we want to allow users to shuffle stuff and add new things. While core functionality should not be removed? eg user should not be able to overwrite pipelines, notebooks, etc |
My understanding from the PR is the following, but @ca-scribner please confirm: The CentralDashboard now will populate links by aggregating the links defined:
By default the CentralDashboard is not configured with any links. So initially the only links shown will be from the Charms that will be related to the CentralDashboard, using the library. If an admin would like some custom links, that aren't to deployed as Charms, then they should use the CentralDashboard's config. Lastly admins can configure the ordering from yet another config in the CentralDashboard. This config will have a default value of: |
@kimwnasptd so it will be Append instead of replace ? |
Yes, it should be append. Since we want the links from the related charms to always be visible. But if a user would like some extra link, they could do it with config of the CentralDashboard. |
This function is described more in this spec, so whatever we decide we should make sure it is clear there. @kimwnasptd has it exactly right. Stating another way just in case it isn't clear, the dashboard charm by default has no sidebar links and sidebar links can be added by:
Removal of links is done by the reverse of the above two (removing a relation, or removing a link from the config). |
main branch of charmed-kubeflow-workflows has a breaking UI change for _quality-checks.yaml that does not work here. Temporarily pinning quality-checks.yaml to a commit
* feat: add user-defined sidebar links This adds a config option additional-sidebar-links which accepts a YAML or JSON formatted input defining additional sidebar links. These are combined with the relation-driven sidebar links. Also: * adds tests for this feature * temporarily pins quality-checks.yaml to a commit because the main branch has a breaking change and previous releases were not versioned
Summary
This PR extends the dynamic sidebar from #118 to allow for user-defined links to be specified via config.
Usage/Testing
To set this config, use an intermediate yaml file:
sidebar.yaml
Result:
To edit the config, do:
Can also be used in conjunction with #118's application-driven links (see #118)
Todo before final review
Merge after #118