Show child objects of a Kustomization

[jpellizzari]

Adds a tabular view of reconciled objects for a given Kustomization:

From this point, it will be easy to convert this to a directed-graph or other more visually appealing visualization. This implementation polls the back-end to "live-update" the view so it would be possible to see the status of objects change.

Before doing so, however, I want to get validation that my querying approach is feasible on the back-end, specifically around the GetReconciledObjects and GetChildObjects calls.

This PR is a PoC without much regard for cluster API server saturation. Rate-limiting can be (hopefully) added after this PR. The case where a Kustomization reconciles thousands of objects may make this approach not feasible. One option would be to grab a couple of "pages" of a List and punt on the rest, with a corresponding UI treatment.

@fluxcd/flux2-maintainers
Some links to the functions in question:

https://github.com/fluxcd/webui/pull/45/files#diff-9388950d28a5b263f35bfb06351027e9ac8a7037268b5a4a2b268b7d83186920R243

https://github.com/fluxcd/webui/pull/45/files#diff-9388950d28a5b263f35bfb06351027e9ac8a7037268b5a4a2b268b7d83186920R297

[stealthybox]

This is awesome.

From a workflow perspective, I consider these separate UX needs:

1. Seeing all of the direct objects the Kustomization applies
   a. getting detail about those top-level objects
2. Diving into the child/sub-objects

The second is a more specialized workflow where you are looking to build a clearer mental model or understand a situation, and it's more valuable when context about these sub-objects is accessible in the UI and displayed up front. (ex: is a Deployment "3/4 Ready" or is a Pod "ContainerCreating")

Diving into the details of objects is a general Kubernetes UX problem that other UI projects like Lens/Octant/Headlamp do well -- it's not Flux specific at that point and that's the logical place to defer to those tools if/when we get to plugin integrations. Alternatively, we can fork/vendor/adapt portions of their UI's.

Because these workflows are different, it's a place where we could split up the query life-cycle in the UI beyond
pagination. ( You already have different funcs for this, so that's great )

Maybe for small catalogs the UI fetches all of this info without asking, but once you're beyond a reasonable amount it needs specific user-action to move to the next page or query sub-objects?

WDYT?

[jpellizzari]

@stealthybox Thanks!

Diving into the details of objects is a general Kubernetes UX problem that other UI projects like Lens/Octant/Headlamp do well -- it's not Flux specific at that point and that's the logical place to defer to those tools if/when we get to plugin integrations. Alternatively, we can fork/vendor/adapt portions of their UI's.

If we can find a generic, customizable (css) component library that can handle organizing the information for each of the Kubernetes objects kinds, I would be willing to adopt it. It would also be a pretty massive amount of work to style those components to make them look uniform.

Because these workflows are different, it's a place where we could split up the query life-cycle in the UI beyond
pagination. ( You already have different funcs for this, so that's great )

Maybe for small catalogs the UI fetches all of this info without asking, but once you're beyond a reasonable amount it needs specific user-action to move to the next page or query sub-objects?

I am thinking we cap how many objects we render in a graph, so each request would have a Limit of 50 (lets say). They each level of the graph would have a max of 50 with some indication to the user that "This isn't the complete graph". Then another tabular view with the traditional pagination controls. For a tabular view, we would probably have to add a selector to filter by Kind for the paging to make sense.

[jpellizzari]

If anyone has any tips on getting "Status" fields to show up using the "sigs.k8s.io/controller-runtime/pkg/envtest" package, that would be really helpful.

I checked out the kustomize-controller tests and I hope I don't have to import all that setup code for each of the controllers.

[hiddeco]

@jpellizzari you may want to have a look at:

• https://github.com/fluxcd/source-controller/blob/refactor-reconcilers/internal/testenv/testenv.go
• https://github.com/fluxcd/source-controller/blob/refactor-reconcilers/controllers/gitrepository_controller_test.go#L1039-L1123

which contains a more barebone setup without much of the Ginkgo structures.

[jpellizzari]

@hiddeco Do I also need to do all of the setup stuff in this file to get a full environment running?: https://github.com/fluxcd/source-controller/blob/refactor-reconcilers/controllers/suite_test.go

It would be great to be able to re-create the different states of the objects to test both the UI and backend, both in this project and others.

[squaremo]

If anyone has any tips on getting "Status" fields to show up using the "sigs.k8s.io/controller-runtime/pkg/envtest" package, that would be really helpful.

I checked out the kustomize-controller tests and I hope I don't have to import all that setup code for each of the controllers.

I'm not sure I understand the question, but if it's "how do I test my code with different statuses of kustomization objects" : you don't need to set up other controllers, just create the objects in question and set their status with a client.