frontend: Add /crs page to display a list of all instantiated custom resources.

[Guilamb]

Description

This pull request addresses the issue of restricted user access to custom resources and the need to view only the instantiated custom resources (#955 ), by introducing a new /crs page in Headlamp that displays a list of all instantiated custom resources, that can be filtered by category.

The /crs page provides users with the capability to view their Resource Status and Definitions without requiring the development of a custom UI. It also allows users to filter namespaces, similar to the existing functionality for Workloads, ensuring restricted permissions are maintained.

Changes

To implement this feature, the following changes were made:

• Added a page that list instantiated Custom resources
  • Used a ResourceListView with its namespaceFilter
• Added a route and a sideBarItem

Fixes: #1962
Signed-off-by: guilhane guilhane.bourgoin@orange.com

[Guilamb]

For the Build Frontend / test (20.x, ubuntu-22.04) action, should I edit the snapshots to add the new sidebar item ?

[joaquimrocha]

I think that at this point it probably makes more sense to have Custom Resources as a top level sidebar entry. Because Custom Resources + Custom Resource Instances looks a bit odd as separate items. But we should do that in a separate PR.

[Guilamb]

I think that at this point it probably makes more sense to have Custom Resources as a top level sidebar entry. Because Custom Resources + Custom Resource Instances looks a bit odd as separate items. But we should do that in a separate PR.

I see. I've been looking at Lens to get an idea of how they organized their CRD section:

So basically, they have a CRD top-level entry with a definition page, and for each API group, they have an entry with the CRDs of the same group.
I feel like this would be difficult to use when you have a large number of CRDs. I think that having a definition entry and an instances entry is a good solution.

I've also looked at how it is on the OpenShift console, but there is only a CRD entry, similar to how it currently is in Headlamp.

[joaquimrocha]

I want to understand better why the instances view is needed. What's the value it brings that you don't get with the current Custom Resources page in Headlamp. IMO, just like you have to navigate between resource kinds across the UI (Pod, ConfigMaps, etc.) before you see the list of definitions, it's similar when going to the list of Resource kinds in the current CR page in Headlamp (where the first column there has the kinds).

[Guilamb]

I want to understand better why the instances view is needed. What's the value it brings that you don't get with the current Custom Resources page in Headlamp. IMO, just like you have to navigate between resource kinds across the UI (Pod, ConfigMaps, etc.) before you see the list of definitions, it's similar when going to the list of Resource kinds in the current CR page in Headlamp (where the first column there has the kinds).

Okay, I'll try to expose what I've noticed using Headlamp to manage crds t'ill now.
The current CRD view is excellent for discovering CRDs. I can easily search for a name, a category or a group and easily found out what the CRD does.
However, when you try to manage custom resources created with these CRDs, it quickly becomes complicated to find your way around, especially if you are not the only one using the cluster, and even more if not all users have the same roles.

The objective of the CR instance page is to ease the management, navigation, and discovery of custom resources.

I have in mind two scenarios for which the CR instances view would be useful.
I'll try to illustrate this as much as possible.

Scenario 1: Two developers with the same roles in the same cluster

---

• Dev 1: Instantiates a MongoDB database using a CRD.
• Dev 2: Learns that his colleague has instantiated a database but does not know what kind of database was created.

Currently, to find it, Dev 2 can sort the CRDs by categories, and let's say there is a "database" category, he will still have to go through each CRD to find the right one.
A CR instances page would let him know exactly what databases are currently instantiated.
It would also simplify management since he could directly see what resources have been instantiated.

Scenario 2: One administrator who has the right to create resources and one developer who can only view resources

---

• Admin: Instantiates CRs for a project.
• Dev: Wants to know what has been instantiated for him. He must go through the CRDs one by one to see which ones he has access rights to.

In a CR Instance view, the developer would only see the CRs that he has the rights to see. If his project is partitioned to a specific namespace, he cannot sort by namespace to see which resources are in his namespace either. By clicking on "Namespaces" and then on his namespace, he only obtains the Resource Quotas, Limit Range, Pods, and Events.

The vision by CR would suddenly add the possibility of navigating more easily in the CRs, having direct visibility on the available resources, and being able to sort and filter the resources by namespace, facilitating navigation in compartmentalized projects.

I've tried to make a short video to illustrate the 2 scenarios. I hope it helps 😄

[joaquimrocha]

@Guilamb Okay. I think this makes sense. Let's mix this together with a higher level Custom Resources sidebar item as we talked about.

[Guilamb]

@Guilamb Okay. I think this makes sense. Let's mix this together with a higher level Custom Resources sidebar item as we talked about.

Should I close #2234 and transfer what have been done there #2234 into this PR ?
Or do you prefer to have 2 distinct PR ?

[joaquimrocha]

Should I close #2234 and transfer what have been done there #2234 into this PR ? Or do you prefer to have 2 distinct PR ?

Hi @Guilamb . Yes please. Transfer it here.
Today in out internal call we discussed this PR and would like to have this feature for the next release, hopefully by next Monday. Let me know if you are able to add it by then. We will help land this.

[Guilamb]

Should I close #2234 and transfer what have been done there #2234 into this PR ? Or do you prefer to have 2 distinct PR ?

Hi @Guilamb . Yes please. Transfer it here. Today in out internal call we discussed this PR and would like to have this feature for the next release, hopefully by next Monday. Let me know if you are able to add it by then. We will help land this.

Hi, Should be ok, I've added the sidebar as required and I'm closing the other PR

[joaquimrocha]

Thank you @Guilamb . I have reviewed the sidebar. I will review the rest later.

[Guilamb]

Thank you @Guilamb . I have reviewed the sidebar. I will review the rest later.

Thanks, I'll correct this. Also when showing the changes to @gberche, he spotted a problem with the filtering in the CR page.
I have correct it and pushed the changes.
Also for the build-frontend test, do I need to do something ?

[illume]

For "Build Frontend / test"... You might need to rebase against main, npm i to get the latest packages, and then regenerate your snapshots again.

The failing "Build Frontend / test plugins" which just hangs on CI is unrelated to this. Ignore this one for now, I am currently working on a fix.

[joaquimrocha]

@Guilamb I think some snapshots are failing. Are you able to update them?

[Guilamb]

@Guilamb I think some snapshots are failing. Are you able to update them?

Hello, I couldn't find out how to update them.

[joaquimrocha]

Closing in favor of #2356 .