Ilya Lobkov
Ilya Lobkov
@slonka is it going to be addressed by https://github.com/kumahq/kuma/pull/10921?
MeshGateway /_rules API: provide matchers for toRules (to know which rules apply to which listeners)
@michaelbeaumont @lahabana if I understand the problem correctly it's not addressed by https://github.com/kumahq/kuma/pull/10726. According to the MADR we'll add `toResourceRules` field which is an array of `ResourceRules` and doesn't imply...
Seems like it's already tested here https://github.com/kumahq/kuma-website/blob/master/.github/workflows/ci.yml#L114
Yes, it's still a limitation. At this moment we can't apply the policy only to some subset of `my-external-service` (like `version=v2`) because all `my-external-service` endpoints are located in the same...
I don't think it makes sense to fix this for old policies. Probably we should just make sure similar use case works for new policies and new external service
Closing since MeshExternalService doesn't have `tags` on individual endpoints, so the problem doesn't exist.
Discussed this today, came up with a code snippet of the usage of such internal structure: ```go // rs.AppOutbounds() // rs.AppOutbounds().Routes() // rs.AppInbounds() // rs.SystemInbounds() // rs.SystemOutbounds() ??? for _,...
Do we even need tags in endpoint metadata if we're planning to create MeshService per split?
> While thinking about: https://github.com/kumahq/kuma/issues/10247 and thinking about syncing to zones with producer/consumer policies it struck me that you could have multiple to entries with different kinds (one could be...
ProxyTemplate to add response header: ```yaml apiVersion: kuma.io/v1alpha1 kind: ProxyTemplate mesh: default metadata: name: custom-template-1 spec: selectors: - match: kuma.io/service: backend_kuma-demo_svc_3001 conf: imports: - default-proxy modifications: - virtualHost: operation: remove...