Dashboard should support custom workload types

[robertpatrick]

Detailed Description

We would like to use the Rancher Dashboard to allow the user to do CRUD operations on custom workload type.

Context

We have custom application workload types (backed by CRDs) related applications using our products/frameworks that are managed by custom K8S operators. We want to expose these workload types in the Rancher Dashboard, allowing the user to view, edit, create, and delete these applications. We want to be able to not only create/edit via your YAML editing mechanism but via custom forms.

We believe that other users will benefit from being able to extend the Rancher dashboard to better support their needs without the need to fork the project.

[richard-cox]

This follows on from https://github.com/rancher/dashboard/issues/5227#issuecomment-1054019234

@nwmac I think I've got the comment right, this is something that should work in the new plugin world (custom edit/detail/lists components with hardcoded routes)?

[catherineluse]

Is this similar to the feature to support custom secret types? https://github.com/rancher/dashboard/issues/6076

If so, we could add a "Custom" option to the workload landing page:

[richard-cox]

@catherineluse It's similar, but it would not be resolved by a generic option. The ask here is to have per-install custom forms

[robertpatrick]

@catherineluse We have our own k8s operators that rely on Custom Resource Definitions. While the Dashboard does detect and display them in the “More Resources” area, it obviously can only display the YAML. We want to add forms to populate the “Config” tab so the our users can do CRUD operations via these forms.

As a side note, we are currently forking your repo and trying to add what we need. We have run into several limitations with reusing the some of the lower-level components. Rather than trying to enhance these components, we made a copy and made them work for our purposes. The lack of a good test suite and the need to periodically pick up new releases drove this decision.

Without a doubt, the biggest missing piece for us is a navigation tree component that supports nested tabs. We need this because some of our existing CRDs are pretty complex, nested structures that contain dynamic lists of complex, nested objects. We are slowly working to try to create our own but since it requires router customization, we have to be careful not to break other parts of the application.

Hope this helps give you the context. I am happy to do a Zoom meeting if you need more information.

[catherineluse]

This is just an idea, but maybe we could extend the questions.yaml functionality and reuse it. We supported configuring these types for custom forms in the past: https://rancher.com/docs/rancher/v2.6/en/helm-charts/creating-apps/#question-variable-reference

Currently those questions.yaml files are only used for generating tabbed forms for filling out Helm chart values, but I can see them also being used to allow users to configure custom forms for custom resources.

The advantage of questions.yaml would be that you could create the forms without Javascript. Then you would only need to write Javascript if you need something weird that questions.yaml doesn't support.

[bashofmann]

I like this, improvements the would automatically also benefit the app marketplace and RKE2 cluster templates.