Show first level of objects created as children of an Application of type `Kustomization`

As a user, I want to be able to see a tree of resources that have been created by a specific Application of type Kustomization.

A Kustomization can effectively create any number of arbitrary objects as its children. These components may be any valid Kubernetes Kind or Custom Resource, even CRD themselves.

Because of this complexity, we will need to develop our full nested tree building functionality in multiple iterations, and each different Kind of object may require different commands to track it’s children.

This ticket will focus only on the first level of resources created by any one specific Kustomization . Consider that a Kustomization may create objects across different namespaces, and it may create Namespaces as well.

Commands

Note:

• All immediate children to a Kustomization will have a specific label matching the name of the parent Kustomization, we will use that label to identify the immediately created objects (in other words, this method will not allow us to track children at any further level or recursion)
• The kinds of objects available in a cluster, besides “built-in” objects on native Kubernetes API, must be dynamically determined.

Step 1: Get a list of all available objects kinds in the cluster:

kubectl api-resources --verbs=list -o name

The above command will return a new-line separated list of all possible object Kinds available in the server, this list must be passed as a string of comma separated values to the following command.

Step 2: Get all resources that match the Kustomization label.

kubectl get {comma separated list of all lines returned by the command avobe} -l kustomize.toolkit.fluxcd.io/name={name of Kustomization} -n {namespace where Kustomization exists} -o json

For sample output please see the following Gist: https://gist.github.com/murillodigital/c96fb943a17a130c91bab8897cfc2079

Tree display / UI

• Each Application should allow for expanding a tree underneath showing the various objects that it created, in this iteration we will focus on the immediate first tier of objects created, as they can nest “infinitely”.

• Each item returned by the get command in Step 2 above must be added as a child node to the applicable Kustomization following the syntax: (Namespace) kind: name. Using the sample output linked above as example, two children nodes would be added below the Kustomization:

(blue-ns) Service: hello-kubernetes-eks-ha
(blue-ns) Deployment: hello-kubernetes-eks-ha

• On click, the full object manifest should be loaded in the editor.

Note: Properties to display and action on hover is still undefined and outside the scope of this ticket.

Important Implementation Details

As stated, each Application may create any number of objects of any Kind, considering K8s CRD model, the Application may create new Kinds altogether that may be proprietary. Our implementation must be generic and abstracted enough to be able to display this level of diversity without having to hardcode specific properties or kinds of objects.

Why it’s important

Both User Personas will have as utmost interest by using the Extension to have visibility into the health and deployment status of any and every resource they have declared in their desired state. Providing a complete view of all those resources is necessary to avoid confusion and misinterpretation of the status of a given deployment.

[murillodigital]

@josefaworks @RandomFractals @usernamehw - We’ve narrowed down the scope of this ticket and I hope the level of detail both in terms of commands as well as implementation is satisfactory, please advise.

I am open to recommendations as to how to best “word” or arrange the node items below the Kustomization, which may not be exactly as suggested in the Tree / UI section of the ticket.

[RandomFractals]

@usernamehw you can take a stab at adding pods and replicasets if you can figure out the kubectl commands for them while we wait for @murillodigital to expand more on that.

maybe handle tree view items to nodes rename first to make it simpler to add others required for this feature: https://github.com/weaveworks/vscode-gitops-tools/issues/76#issuecomment-924129209