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

Use proper appProtocol for remote MeshService #12702

Open
jakubdyszkiewicz opened this issue Jan 29, 2025 · 0 comments · May be fixed by #12709
Open

Use proper appProtocol for remote MeshService #12702

jakubdyszkiewicz opened this issue Jan 29, 2025 · 0 comments · May be fixed by #12709
Assignees
Labels
kind/bug A bug triage/accepted The issue was reviewed and is complete enough to start working on it
Milestone

Comments

@jakubdyszkiewicz
Copy link
Contributor

Kuma Version

2.9.3

Describe the bug

Whenever we try to apply HTTP related policies on remote MeshService like idleTimeout of MeshTimeout or MeshHealtchCheck the setting is not applied.

To Reproduce

Create MeshService in one zone, create client in another zone and policy with idleTimeout.

Expected behavior

Timeout should be applied

Additional context (optional)

It seems the problem is that whenever we generate clusters for MeshServices, we take protocol information from MeshContext#ServicesInformation, but we should take it directly from MeshService object.
It breaks, because when we build ServiceInformation, we infer protocol from endpoints and endpoints for remote MeshService do not have tags which is correct.
I think we should just use appProtocol from the MeshService object instead of using ServicesInformation

@jakubdyszkiewicz jakubdyszkiewicz added kind/bug A bug triage/pending This issue will be looked at on the next triage meeting labels Jan 29, 2025
@lukidzi lukidzi linked a pull request Jan 29, 2025 that will close this issue
@lukidzi lukidzi self-assigned this Jan 30, 2025
@lukidzi lukidzi added this to the 2.10.x milestone Jan 30, 2025
@bartsmykla bartsmykla 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 Feb 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug A bug triage/accepted The issue was reviewed and is complete enough to start working on it
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants