Closed slonka closed 2 months ago
Name | Link |
---|---|
Latest commit | c568167b9cb4fcf20f1d55a3212156ab5b267238 |
Latest deploy log | https://app.netlify.com/sites/kuma/deploys/6615269f15535b0008287a7b |
Deploy Preview | https://deploy-preview-1717--kuma.netlify.app |
Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
Lighthouse |
1 paths audited Performance: 90 (π΄ down 5 from production) Accessibility: 90 (no change from production) Best Practices: 100 (no change from production) SEO: 85 (no change from production) PWA: 80 (no change from production) View the detailed breakdown and full score reports |
To edit notification comments on pull requests, go to your Netlify site configuration.
The examples in the blogpost / httproute / tcproute look like they should work with the marketplace demo but they actually don't (
kuma.io/service
is the same, but version tags and prefix is wrong).This combined with the "catch all" route causes an invalid MeshHTTPRoute to "sort of work" without any warning and can cause confusion down the line.
E.g. if we take the old MeshHTTPRoute with a 90/10 split:
this produces the following envoy configuration:
the first two matches will not match (not matching version/path) and the "catch all" will make the requests work with 50/50 split.
I think this is a bug in "catch all" mechanism. I think we should add the "prefix" to existing split not create a new "catch all" route. So if there is no match you get a 404 and you immediately know that there is something wrong with
MeshHTTPRoute
and not silently ignore the not working policy. WDYT? @bartsmykla (original author of https://github.com/kumahq/kuma/pull/6993) @lobkovilya ( https://github.com/kumahq/kuma/issues/6758 ) and @michaelbeaumont ( this docs ) also @lahabana.Kuma issue: https://github.com/kumahq/kuma/issues/9885
Did you sign your commit? Instructions yes
Have you read Contributing guidelines? yes