Breadcrumb navigation not always working

[frightener]

Hello,

the breadcrumb navigation doesn't seem to be working in all cases.
I'm currently viewing the node-exporter Daemon Set and the navigation shows: Workloads -> Daemon Sets -> node-exporter.

The Workloads link is correct and works: http://127.0.0.1:7777/#/overview/namespace/openshift-monitoring/workloads

The Daemon Sets link on the other hand seems broken: http://127.0.0.1:7777/#/overview/namespace/openshift-monitoring/workloads/daemon-sets/node-exporter/%5Coverview%5Cnamespace%5Copenshift-monitoring%5Cworkloads%5Cdaemon-sets

Regards,

Christian

[GuessWhoSamFoo]

Hi Christian! Thanks for the bug report. It looks like a malformed link with bad url encoding as well. Could you share more information about where that link came from?

The only places I can find are the datagrid listing, resource viewer, and controlled by in the metadata tab from one of the pods which appear okay on inspection in 0.16.2

[frightener]

I can see the malformed link anytime there is a navigation path with two components.

I click on Workload->Pods and then on one of the pods that are available in the current namespace. Above the pod name I have the following navigation path:

Workloads > Pods > node-exporter-7zhqr

"Workloads" and "Pods" are links, but only the first one is correct and the second one is malformed. This is true for other views as well (e.g. Workloads->Daemon Sets).

I'm using 0.16.2 as well.

[mklanjsek]

Hey @frightener, I started looking into this but have hard time reproducing it in my setup. What is the OS and browser you are using? Looks like you were using OpenShift in above example - do you see the issue for deployments not generated by OpenShift? Anything that can help narrow down specific environment detail triggering the issue would be helpful.

What appears to be happening is that the breacrumb urls contain additional copy of resource path, where path is for some reason separated by backslash and encoded, so path separators show up as %5c.

[lgellrich]

Hi @mklanjsek ,

I'm actually observing the very same issue only on Windows, while a Linux client with the same octant version and Kubernetes cluster works as expected.

Looking at the Websocket traffic on Windows I do receive the following message:

{
  "type": "event.octant.dev/content",
  "data": {
    "content": {
      "title": [
        {
          "config": {
            "value": "Workloads",
            "ref": "/overview/namespace/kube-system/workloads"
          },
          "metadata": {
            "type": "link",
            "title": [
              {
                "metadata": {
                  "type": "text"
                },
                "config": {
                  "value": ""
                }
              }
            ]
          }
        },
        {
          "config": {
            "value": "Pods",
            "ref": "\\overview\\namespace\\kube-system\\workloads\\pods"
          },
          "metadata": {
            "type": "link",
            "title": [
              {
                "metadata": {
                  "type": "text"
                },
                "config": {
                  "value": ""
                }
              }
            ]
          }
        },
        {
          "metadata": {
            "type": "text"
          },
          "config": {
            "value": "coredns-6f5c7bbdfb-8kmwb"
          }
        }
      ],
      ...
    }
  }
}

This lead me to this line: /~https://github.com/vmware-tanzu/octant/blob/660f49977bf1d59de6a3ab1c9b4b9371a424206e/internal/describer/object.go#L124
The package path/filepath is OS specific, which causes the parent to be resolved with backslash on Windows.

Switching from "path/filepath" to "path" and using path.Dir(nameLink.Ref()) instead resolves the issue.

[mklanjsek]

Thank you @lgellrich, that now makes sense!

Good news is that that code will get removed with #1716 and I'll make sure we don't use filepath.Dir anywhere.

[mklanjsek]

Fixed by #1796