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
Fix service entry merge #50711
Fix service entry merge #50711
Conversation
Skipping CI for Draft Pull Request. |
d17ed67
to
8dc4a7f
Compare
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.
Much cleaner than the previous implementation IMO. LGTM
@@ -94,15 +94,26 @@ func (es *EndpointShards) Keys() []ShardKey { | |||
|
|||
// CopyEndpoints takes a snapshot of all endpoints. As input, it takes a map of port name to number, to allow it to group | |||
// the results by service port number. This is a bit weird, but lets us efficiently construct the format the caller needs. | |||
func (es *EndpointShards) CopyEndpoints(portMap map[string]int) map[int][]*IstioEndpoint { | |||
func (es *EndpointShards) CopyEndpoints(portMap map[string]int, ports sets.Set[int]) map[int][]*IstioEndpoint { |
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.
can we initialize the ports sets from portMap in this function
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.
yeah that makes sense. I was thinking it was faster to do it this way, but it shouldn't be
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.
LG, thanks
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.
tks
In response to a cherrypick label: new pull request created: #50773 |
In response to a cherrypick label: #50711 failed to apply on top of branch "release-1.20":
|
In response to a cherrypick label: new issue created for failed cherrypick: #50774 |
In response to a cherrypick label: #50711 failed to apply on top of branch "release-1.21":
|
In response to a cherrypick label: new issue created for failed cherrypick: #50775 |
Throwing in my attempt at fixing #50478.
Note this pairs well with #50690 to fix the EDS issue (#50688). With both PRs, all known issues are fixed.
There are a few approaches here:
Approach 1
Up to 1.19.8 the created clusters are one per port without LB between ports:
This behavior is, IMO, what a user expects. While the port names are colliding, user probably doesn't really care -- they care about the number. This also is the behavior if the port names did not collide.
This was the behavior in 1.19 and what I implemented here.
Approach 2
Cross product the ports:
I don't see a good reason to ever want this approach
Approach 3
Merge down to a single service port, but with an endpoint per port. Implemented in #50691
The difference from 1 and 3 comes down to how we intepret them. In a
Service
, they key could logically be considered the name OR the number; because they must be distinct, there is never any difference between those. We happen to use name throughout Istio, but that is an internal detail.This PR takes the opposite approach and makes the number effectively the key.
Note: I 100% agree the approach here is incredibly hacky. If we want to go down this route, I will try to make it suck less and add tests.