Support Custom Resource Definitions

maciaszczykm commented 7 years ago

Third Party Resources support was removed in #2491 as it was causing some issues. We should add support for Custom Resource Definitions. It was started in #2449 by @kenan435.

nikhita commented 6 years ago

@maciaszczykm To clarify, this means that we don't need to support TPRs anymore, right? (TPRs have been removed in 1.8)

floreks commented 6 years ago

Correct.

EronWright commented 6 years ago

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.

klustria commented 6 years ago

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.

floreks commented 6 years ago

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).

fabiand commented 6 years ago

Yes, please bundle logic and UI (cockpit does it in a similar way)

wild-endeavor commented 5 years ago

Is there any update on this? Still running into this problem on the dashboard. Thanks!

imdhruvgupta commented 5 years ago

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.

maciaszczykm commented 5 years ago

@imdhruvgupta Sorry, but this is frozen for now as it is a possible topic for Google Summer of Code.

imdhruvgupta commented 5 years ago

@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.

xxmyjk commented 5 years ago

Any idea on this?

eloyekunle commented 5 years ago

I am currently working on this issue for GSoC.

eloyekunle commented 5 years ago

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.

javajon commented 5 years ago

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.

floreks commented 5 years ago

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.

javajon commented 5 years ago

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.

eloyekunle commented 5 years ago

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?

maciaszczykm commented 5 years ago

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.

floreks commented 5 years ago

+1 for pinning commonly accessed CRDs

javajon commented 5 years ago

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.

floreks commented 5 years ago

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.

javajon commented 5 years ago

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.

eloyekunle commented 5 years ago

The initial frontend implementation of CRDs has now been merged in https://github.com/kubernetes/dashboard/pull/4030. Please share your thoughts and observations. Cheers!

eloyekunle commented 5 years ago

This support has now been added to the dashboard.

/close

k8s-ci-robot commented 5 years ago

@eloyekunle: Closing this issue.

In response to [this](https://github.com/kubernetes/dashboard/issues/2493#issuecomment-528888350): >This support has now been added to the dashboard. > >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

kubernetes / dashboard