Support Custom Resource Definitions
maciaszczykm opened this issue · 25 comments
@maciaszczykm To clarify, this means that we don't need to support TPRs anymore, right? (TPRs have been removed in 1.8)
Correct.
I bet that this has been discussed before, but I'll ask anyway. Would it be desirable that the UI be made extensible such that custom resources are rendered by appropriate UI plugins? I have a doubt that the generic experience that is articulated in docs/design/thirdpartyresources.md will be adequate.
Will this also cover Custom Resources created through API aggregation? This k8s doc https://kubernetes.io/docs/concepts/api-extension/custom-resources/#should-i-add-a-custom-resource-to-my-kubernetes-cluster states “Consider API aggregation if….. You want to view your new types in a Kubernetes UI, such as dashboard, alongside built-in types.“, but this seem to be not true at the moment.
CRD support has not been implemented yet. I think that we could start with generic solution similar to old TRP support and give possibility to enhance the UI using third-party plugins. We do plan to introduce plugins but still haven't decided what will be the modifications scope of such plugins (how exactly will they be able to modify UI).
Yes, please bundle logic and UI (cockpit does it in a similar way)
Is there any update on this? Still running into this problem on the dashboard.
Thanks!
Hi @maciaszczykm @floreks ,
I'm Dhruv Gupta pursuing B.Tech in Information Technology. I am proficient in Javascript and have done some work in Typescript and Angular as well. I would like to make to proposal for this feature and would like to work on it.
@imdhruvgupta Sorry, but this is frozen for now as it is a possible topic for Google Summer of Code.
@imdhruvgupta Sorry, but this is frozen for now as it is a possible topic for Google Summer of Code.
@maciaszczykm Okay, No problem! Given the opportunity I would like to work on it during GSoC 2019. Any help would be very appreciable regarding making a good proposal.
Any idea on this?
I am currently working on this issue for GSoC.
These are the mockups for the frontend implementation:
- Sidebar Menu and CRD List
Sidebar menu is dynamically populated from the server.
- CRD Detail Page
The details of the CRD itself is displayed and objects created using that CRD are listed below.
- Object Detail Page
Shows the object details in structured format.
Please share your thoughts.
Good to see progress on this and nice mocks.
CRDs are not namespaced and are global to the cluster, therefore a single menu choice under Cluster. Makes more sense to have a single line called "Custom Resource Definitions" under "Cluster". Clicking on that would present a paged list of the dozens, hundreds of CRDs (Istio has 51 all by itself).
Don't put it under the "Namespace" dropdown as all those choices are relative to the selected namespace.
The primary CRD list in the context pane should first show CRDs grouped by their "Group". From that main pane each item can be drilled down on to see detailed descriptions.
I'd still consider leaving it on the bottom, maybe just use additional separator. Leaving registered CRDs under 'Custom Resource Definition' entry would make it easier to access them.
If we move it to the top then we should change CRDs list view to only list registered CRDs, then user would have to click on it to see its' details and instances.
There are pros and cons for both approaches. We should discuss it more.
The left menu is currently not a place to enumerate individual resources. The only exception to that is the namespaces as a dropdown to allow the menu to change the selections to a specific namespace context.
Leaving it on the sidebar
Pros
- Makes the registered CRDs easily accessible in the sidebar. You can click on a CRD and it takes you straight to the CRD's details page.
Cons
- Clusters can have lots of CRDs, dozens of them. This can make the sidebar very long in such cases.
Any other Pros and Cons I'm missing?
Possible alternatives
Searchable sidebar
Add the CRD menu option to the top under Cluster, with an icon beside it which opens a search box on click. E.g. Managing projects for a Github Issue/PR:
.
Any other suggestions?
I'd start with just a CRD entry in the menu and then perhaps allow to "pin" some of the CRD types to the menu. You can store config globally in the config map for example.
+1 for pinning commonly accessed CRDs
CRDs are simply similar to many objects/resources/items in K8s. Pods, deployments, secrets, nodes, namespaces etc. Why do anything special just for CRDs on the sidebar? If CRDs search or pinning or any other UX construct is added, then this slippery slope would add the expectation that searching and pinning would be available for all other K8s items.
KISS principle:
- Click on Cluster | Namespace and you get a list of namespaces (paged). Click on the namespace and you get further details.
- Click on Pods and you get a list of Pods (paged). Click on the pod and you get further details.
- Click on Cluster | Custom Resource Definitions and you get a list of CRDs (pages). Click on the CRD and you get further details.
This would make the introduction of CRDs consistent with the rest of the dashboard design. Users would expect this consistency.
Other actions such as pinning, searching are actions that could be proposed should be for all k8s resources and outside the scope of just CRDs.
Keep the first release of CRD listing simple and clean.
Custom Resource Definition is similar to Pod resource which has an exclusive entry in our menu. It defines a new resource with its own properties. After we create CRD, we can create instances of this CRD. We could think of a Pod as a predefined Custom Resource Definition and kubernetes-dashboard-pod-xxx would be an instance of it. Every CRD registers its own endpoints for listing, creating, updating, removing instances. Same as default K8S resources.
Following this logic, every CRD should have its own entry in the menu and then after clicking on it, the user would see instances of this CRD (same as with pod list).
Right now if we follow what you have described, we will see a list of definitions. We can compare that to displaying a view with an actual Cluster|Namespace|Node|Pod|Deployment etc. list. After we click on the definition, we will see the list of actual instances and then if we pick one, its details.
Good to call out that distinction of CR Definition vs instance of the CRD. There are many other standard Kubernetes "Kinds" seemingly missing from the left side menu. As of now the only instances of Kinds on the left side are "namespaces", but that just to change hte menu context to the namespace. All other menu actions are just general definition picks, no instances.
As the left side menu stands now, people benefit from a simple list to quickly find things. Low cognitive load. Perhaps overall, there could be a new UI construct to handle all the other K8s resources and resource instances, outside of the boxed left side menu. Something outside the scope of CRDs.
After we click on the definition, we will see the list of actual instances and then if we pick one, its details.
or
After we click on the definition, we will see the list of definitions. If we pick one CRD item the instances associated with that CRD are listed.
...works for me.
The initial frontend implementation of CRDs has now been merged in #4030. Please share your thoughts and observations. Cheers!
This support has now been added to the dashboard.
/close
@eloyekunle: Closing this issue.
In response to this:
This support has now been added to the dashboard.
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.