[UI] Change graph styling

[bia]

Follow up on #1889 This styling corrects the hierarchy (git repo is the parent), highlights the kustomization node (we are on that kustomization's detail page), and clarifies the structure with the object type instead of its name in bold on each node.

~The question that remains is what to do with the Kustomization Automation node.~ The Kustomization Automation node will be removed as per #1597

~In observability stand-up @luizbafilho suggested that we add it as a parent together with the git repository : ~

In pesto stand-up, @bigkevmcd was unclear about why we would be differentiating a kustomization from its automation in the graph and suggested that we remove it [and by now we've all agreed on this option] :

~@joshri @jpellizzari, which option do you prefer?~

[bia]

@yiannistri also suggests :

• It seems sensible to have the source artifacts at the top. So GitRepository/HelmRepository/Bucket should probably be at the top because these usually tell Flux where to pull the rest of the artifacts
• Below them you would typically have either HelmChart/HelmReleases if the source above was a HelmRepository or a KustomizationAutomation if the source above was a GitRepository. The KustomizationAutomation is a bit tricky because it may refer to a Kustomization file (which specifies exactly which files to apply) or it may refer to a directory in the git repository (which tells Flux to apply all the files from the directory)

It wouldn’t be wrong to put the KustomizationAutomation at the same level as the GitRepository but this is somewhat different from the mental model I have in my head when troubleshooting Flux. First, I’d look at the source artifacts to ensure that they have been updated based on a commit. Then I’d look in the HelmRelease or KustomizationAutomation manifests to see if they have been applied without errors.

[bigkevmcd]

While a Kustomization can reference a kustomization.yaml file in a repo, it does not appear in the cluster, and I'm not aware of any easy way to find out if a Kustomization used a kustomization.yaml or generated one automatically.

[bigkevmcd]

And I agree, start with the source (GitRepository, Bucket), then check the source dependency that you believe is failing (Kustomization).

[jpellizzari]

@bia Not sure what the difference between a Kustomization and KustomizationAutomation would be in the example. I believe those would be the same object in Kubernetes.

I am only asking because it is deliberately called out here. Source -> Kustomization -> ReconciledObjects makes sense to me :+1:

[bia]

@bia Not sure what the difference between a Kustomization and KustomizationAutomation would be in the example. I believe those would be the same object in Kubernetes.

@jpellizzari I feel the same, I only differentiated between Kustomization and KustomizationAutomation because that is on the existing graph. Let's remove it.

[jpellizzari]

^^ That is a bug: https://github.com/weaveworks/weave-gitops/issues/1597

:+1: on removing it

[bia]

@joshri so the final design is the following :

[JamWils]

So far using this in real world scenarios I think this needs to go vertical. I.e. the parent to child relationship flows from left to right instead of top to bottom. Would this change your cell design @bia? I would expect to be able to scroll vertical down the page and not have to adjust the canvas space. cc: @jpellizzari and @joshri

[jpellizzari]

Down for however we want to do it, but keep in mind the scaling factor will be “wider” not “deeper”: we only go a couple children deep, but we could go thousands of objects wide, depending on how many things a Kustomization produces.

On Tue, May 3, 2022 at 12:06 PM James Wilson @.***> wrote:

So far using this in real world scenarios I think this needs to go vertical. I.e. the parent to child relationship flows from left to right instead of top to bottom. Would this change your cell design @bia https://github.com/bia? I would expect to be able to scroll vertical down the page and not have to adjust the canvas space. cc: @jpellizzari https://github.com/jpellizzari

— Reply to this email directly, view it on GitHub https://github.com/weaveworks/weave-gitops/issues/1956#issuecomment-1116460902, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVMEUJDNIKPZQG5G5IFH73VIF2LLANCNFSM5T3POLOQ . You are receiving this because you were mentioned.Message ID: @.***>

[JamWils]

Let's leave it as is for now. Can we create a separate issue to fix the layout issues from the styling issues? I would rather we prioritize making sure that we have the flow from Source -> Automation -> Children reconciled by automations.