-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
policy: Serve EgressNetwork responses #13206
Merged
Merged
Changes from 1 commit
Commits
Show all changes
11 commits
Select commit
Hold shift + click to select a range
130050d
serve EgressNetwork responses
zaharidichev 4144b19
handle egress network changes
zaharidichev 903005e
simplify types
zaharidichev c288874
fix not found integration test
zaharidichev a53f573
address feedback
zaharidichev 501c646
remove PolicyKind type
zaharidichev 8b29501
update proxy api
zaharidichev 3e1573a
switching test
zaharidichev 1ffaa3b
more feedback
zaharidichev e0b58fe
depend on proxy-api c5648ae2a1e405cc6b8aca20522356ebdf20f1ea
zaharidichev 06e2d3a
clippy
zaharidichev File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm surprised to see TrafficPolicy here in the discover target. I think this means that the TrafficPolicy is looked up once at the beginning of the discovery lookup but then never updated. If the EgressNetwork resource is edited to change the TrafficPolicy, I don't think the discovery watches will see that change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This actually leads to a more difficult question about EgressNetwork mutability and ip address.
For services, a service's IP address will never change for the life of that services which means we can look up the service by IP once at the beginning of the discovery stream and never again.
For EgressNetworks, on the other hand, they encompass a range of IP addresses and that range can change if the EgressNetwork resource is edited. What happens when a discovery stream is started on an IP address that is in an EgressNetwork, but then the EgressNetwork is edited to no longer include that IP in it's network range? Or vice versa, what if an EgressNetwork is edited to include an IP address that was used for an already started discovery stream?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It really seems like we need to take a different approach for EgressNetworks compared to the approach we have for services in the outbound index. Perhaps we can take advantage of the fact that cluster networks are immutable. When a discovery lookup comes in, we can look at if it's in the cluster network and send it to the service index or if it's out of the cluster network, then we can send it to the egress index.
The egress index will likely need to have watches indexed by ip address so that we can update the appropriate watches whenever an EgressNetwork resource changes and may encompass watches that it did not before or stop encompassing watches that it used to.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good points.. Will think about it a bit more.