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.

Sign up for GitHub

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

Jump to bottom

Development environment (spawned with make local-setup) does not support targetRef in the wasmplugin object. #342

Closed
eguzki opened this issue Nov 28, 2023 · 2 comments
Closed

Development environment (spawned with make local-setup) does not support targetRef in the wasmplugin object. #342

eguzki opened this issue Nov 28, 2023 · 2 comments
Assignees
@eguzki
Labels
kind/enhancement New feature or request
Milestone
v0.6.0

Comments

@eguzki
Copy link
Contributor

eguzki commented Nov 28, 2023 •
edited
Loading

Motivated by the deprecation of workload selectors on the issue #302, we found an Istio issue on using the targetRef of the wasmpluging when the targeted gateway is istio-ingressgateway (or any manually deployed Gateway API gateway). Thus, currently, our development environment (spawned with make local-setup) does not support targetRef in the wasmplugin object.

Istio engineers provided a workaround, but clearly stated that it was intended not to apply to Istio ingress gateway.

So, there are three ways we can take in order to deprecate workload selectors with targetRef:

  • Replace istio-ingressgateway with automatically deployed Gateway

Note: Sometimes it is very handy to switch Envoy's log level to debug to see what decisions are being maked at the gateway level regarding auth and rate limiting filters. For the istio-ingressgateway, it is just about k edit deployments istio-ingressgateway -n istio-system and then set "--proxyLogLevel=debug". However, for automatically deployed Gateways, the deployment is fully reconciled and modifications of the log level are not allowed.

  • Investigate the workaround provided in the Istio issue and keep using Istio ingress gateway.
  • Postpone the replacement of the workload selectors with the targetRef and wait for Istio to fix it (if they ever decide to fix it).

PS: My take is to go for the first one, i.e. use an automatically deployed gateway. Some of the Istio design decisions regarding Gateway API on-boarding are explicitly avoiding Istio ingress gateway, and more issue may happen in the future like this one. Postponing does not seem a good option as well IMO. The targetRef is clearly a simplification that can benefit the users of kuadrant and does not seem fair to block it because there is an issue with out development environment.
@eguzki eguzki moved this to Needs refinement in Kuadrant Service Protection Nov 28, 2023
@eguzki eguzki mentioned this issue Nov 28, 2023
Closed
2 tasks
@eguzki eguzki added the kind/enhancement New feature or request label Nov 28, 2023
@eguzki eguzki moved this from Needs refinement to In Progress in Kuadrant Service Protection Nov 28, 2023
@alexsnaps
Copy link
Member

@adam-cattermole that's what I was talking about

@alexsnaps alexsnaps moved this to In Progress in Kuadrant Dec 8, 2023
@alexsnaps alexsnaps added this to the v0.6.0 milestone Dec 8, 2023
@alexsnaps
Copy link
Member

#298 did:

Replace istio-ingressgateway with automatically deployed Gateway

@github-project-automation github-project-automation bot moved this from In Progress to To test in Kuadrant Service Protection Dec 11, 2023
@github-project-automation github-project-automation bot moved this from In Progress to Done in Kuadrant Dec 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@eguzki eguzki

Labels
kind/enhancement New feature or request
Projects
Kuadrant
Archived in project
Kuadrant Service Protection
Status: To test
Milestone
v0.6.0
Development

No branches or pull requests
2 participants
@alexsnaps @eguzki