Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

meshservice: Enable linking of Outbounds in DataPlaneViz to MeshService detail page #2848

Open
johncowen opened this issue Sep 2, 2024 · 8 comments
Assignees
Labels
kind/feature New feature triage/accepted The issue was reviewed and is complete enough to start working on it
Milestone

Comments

@johncowen
Copy link
Contributor

Description

For the dataplane overview viz we use Envoy stats as the data source to generate the viz/GUI, current this generates the following Outbounds:

Screenshot 2024-09-02 at 13 56 39

The links here take us to the following URL:

http://localhost:5681/gui/meshes/default/data-planes?s=service:demo-app_kuma-demo_msvc_5000

i.e. Show me the list of dataplanes that have the kuma.io/service equalling demo-app_kuma-demo_msvc_5000, which of course don't exist. Therefore we show an empty list.

The cards in the above screenshot should instead read (ideally) demo-app, and link to:

http://localhost:5681/gui/meshes/default/services/mesh-services/demo-app.kuma-demo/overview

Note: In some environments the name used in the above screenshot can contain the hash used for identifying dataplanes in the backend i.e. redis-2a3s4d5f_kuma-demo_msvc_5000.


Overall this presents a problem because it "looks like" we can only use - and _ as separators/markers, which are also valid user values, meaning any sort of parsing/regexing we do is not going to be guaranteed to work correctly.

@johncowen johncowen added triage/pending This issue will be looked at on the next triage meeting kind/feature New feature labels Sep 2, 2024
@johncowen johncowen added this to the 2.9.x milestone Sep 2, 2024
@jakubdyszkiewicz jakubdyszkiewicz added triage/accepted The issue was reviewed and is complete enough to start working on it and removed triage/pending This issue will be looked at on the next triage meeting labels Sep 2, 2024
@jakubdyszkiewicz
Copy link
Contributor

Triage: it requires backend work, because of name hashes. For upcoming release let's just not display the link.

@johncowen
Copy link
Contributor Author

PR to not display the link for now:

#2853

johncowen added a commit that referenced this issue Sep 4, 2024
During parsing of the Envoy stats responses, if we find a clustername with `_msvc_` (or related), we mark that cluster/outbound as having a `kind` of `MeshService`.

Later on in the view, we can decide whether to add a link to the cards service depending on its `kind`.

Currently we only link cards with empty kinds. i.e. if its not a MeshService, MeshMultiZoneService or a MeshExternalService we don't link the card.

See linked issue for more details #2848

Signed-off-by: John Cowen <[email protected]>
@johncowen
Copy link
Contributor Author

FYI #2853 is in, I'm guessing we just need to bump the milestone here seeing as it sounds like we need backend support which won't come until after the upcoming release (see triage comment)

I'll leave 2.9 for now but guessing we can bump that when the milestone gets reviewed.

@johncowen johncowen modified the milestones: 2.9.x, 2.10.x Sep 9, 2024
@lahabana
Copy link
Contributor

@johncowen to search for a backend issue to relate to this.

@johncowen
Copy link
Contributor Author

@jakubdyszkiewicz do you have any insight on the backend work related to this issue? Not sure if there is already an issue, or whether you had any thoughts on whats required for the backend support we need for this?

@lahabana
Copy link
Contributor

lahabana commented Nov 6, 2024

@johncowen is this what you are looking for: kumahq/kuma#11865

@johncowen
Copy link
Contributor Author

I don't think so but not totally sure, shall we remove the accepted label so we can discuss in triage? I won't be working this until way after the next triage anyway. If not, we could also just chat through this next time we sync.

@johncowen johncowen added triage/pending This issue will be looked at on the next triage meeting and removed triage/accepted The issue was reviewed and is complete enough to start working on it labels Nov 14, 2024
@lobkovilya lobkovilya added triage/accepted The issue was reviewed and is complete enough to start working on it and removed triage/pending This issue will be looked at on the next triage meeting labels Nov 18, 2024
@lobkovilya
Copy link
Contributor

Triage: waiting on kumahq/kuma#12044

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature New feature triage/accepted The issue was reviewed and is complete enough to start working on it
Projects
None yet
Development

No branches or pull requests

4 participants