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

Migrate from using bind_to_port=false to filter chains. #10533

Open
PiotrSikora opened this issue Dec 18, 2018 · 14 comments
Open

Migrate from using bind_to_port=false to filter chains. #10533

PiotrSikora opened this issue Dec 18, 2018 · 14 comments
Assignees
Labels
area/networking kind/enhancement lifecycle/staleproof Indicates a PR or issue has been deemed to be immune from becoming stale and/or automatically closed
Milestone

Comments

@PiotrSikora
Copy link
Contributor

Envoy removed support for bind_to_port (envoyproxy/envoy#5288), which has been marked as deprecated_v1 since 2017-08-15 (envoyproxy/data-plane-api@86de1f2), and announced to be removed on 2018-03-15 (https://groups.google.com/forum/#!topic/envoy-announce/Lb1QZcSclGQ), so it was long time coming, but we cannot upgrade Envoy in Istio Proxy now...

The feature was superseded by filter chains, and so we should migrate from using multiple listeners with bind_to_port=false to a single listener with multiple filter chains.

cc @duderino @costinm @rshriram @knrc

@PiotrSikora PiotrSikora added this to the 1.2 milestone Dec 18, 2018
@PiotrSikora
Copy link
Contributor Author

PiotrSikora commented Dec 19, 2018

Re-removal tracked upstream: envoyproxy/envoy#5355

@PiotrSikora
Copy link
Contributor Author

Note: Migration to filter chains will require split to separate inbound/outbound listeners (see: #6259), since we need to have different listener filters in both cases (notably, we need TLS Inspector in the inbound listener for the PERMISSIVE mode, but we cannot have in the outbound listener).

@duderino
Copy link
Contributor

duderino commented Feb 5, 2019

@philrud this would be a good first meaty bug.

@duderino
Copy link
Contributor

@phildrud how about we give this to @silentdai instead? He's going to work on the filter chain discovery service in the Envoy-side, so it may make sense for him to do the control plan side too

CC @htuch and @alyssawilk

@stale
Copy link

stale bot commented May 29, 2019

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.

@stale stale bot added the stale label May 29, 2019
@lambdai
Copy link
Contributor

lambdai commented May 29, 2019

Working in progress. Currently we cannot move to filter chain due to user impact. If we move migrate the outbound listener to adopt filterchain, any filter chain change will drain the listener and all the filter chains are impacted.
We need Filter Chain Discovery Service, or a subset which restrict the impact of other filter chain.

@stale stale bot removed the stale label May 29, 2019
@lambdai lambdai assigned lambdai and unassigned duderino Jun 7, 2019
@rlenglet rlenglet modified the milestones: 1.4, 1.3 Jul 9, 2019
@lambdai
Copy link
Contributor

lambdai commented Aug 27, 2019

The progress we made as of istio 1.3:

  • split capture inbound and outbound listeners
  • the virtual inbound listener is fully migrated to filter chains

in istio 1.4
Implement FCDS in envoy and adopt in istio
istio will deprecate bind_to_port listeners outbound listeners

@duderino
Copy link
Contributor

Thanks for the update. I'm moving this to the next release so we don't keep nagging it for the 1.3 release.

@duderino duderino modified the milestones: 1.3, 1.4 Aug 27, 2019
@howardjohn
Copy link
Member

@lambdai are we expecting FCDS to be done by 1.4? Seems like this is likely a 1.5 or later item?

@duderino
Copy link
Contributor

I think @lambdai should work on this nowish, but I have no opinion on whether 1.4 or 1.5 is feasible

@lambdai
Copy link
Contributor

lambdai commented Sep 24, 2019

The goal is to be done at 1.4 unless higher priority task reaches. E.g vulnerability...

@duderino
Copy link
Contributor

Well stated :)

@howardjohn howardjohn modified the milestones: 1.5, 1.6 Jan 10, 2020
@istio-policy-bot istio-policy-bot added the lifecycle/stale Indicates a PR or issue hasn't been manipulated by an Istio team member for a while label Mar 23, 2020
@brian-avery brian-avery modified the milestones: 1.6, Backlog Mar 24, 2020
@istio-policy-bot istio-policy-bot added the lifecycle/automatically-closed Indicates a PR or issue that has been closed automatically. label Apr 7, 2020
@incfly incfly reopened this Apr 24, 2020
@istio-policy-bot istio-policy-bot removed the lifecycle/stale Indicates a PR or issue hasn't been manipulated by an Istio team member for a while label Apr 24, 2020
@incfly incfly added lifecycle/staleproof Indicates a PR or issue has been deemed to be immune from becoming stale and/or automatically closed and removed lifecycle/automatically-closed Indicates a PR or issue that has been closed automatically. labels Apr 24, 2020
@howardjohn
Copy link
Member

Update 6 years later: this is still desired, but low priority

@howardjohn
Copy link
Member

We will want to implement #36596 as part of this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/networking kind/enhancement lifecycle/staleproof Indicates a PR or issue has been deemed to be immune from becoming stale and/or automatically closed
Projects
Status: P1
Development

No branches or pull requests

10 participants