-
Notifications
You must be signed in to change notification settings - Fork 347
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
Adds Support for Managing Gateway Status Addresses #352
Conversation
Codecov Report
@@ Coverage Diff @@
## main #352 +/- ##
==========================================
- Coverage 60.62% 59.96% -0.66%
==========================================
Files 32 33 +1
Lines 3220 3317 +97
==========================================
+ Hits 1952 1989 +37
- Misses 1159 1217 +58
- Partials 109 111 +2
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
internal/gatewayapi/translator.go
Outdated
// OwningGatewayNameLabel is the owner reference label used for managed infra. | ||
// The value should be the name of the Gateway used to CRUD the Service. | ||
OwningGatewayNameLabel = "gateway.envoyproxy.io/owning-gateway-name" | ||
// OwningGatewayNamespaceLabel is the owner reference label used for managed infra. | ||
// The value should be the namespace of the Gateway used to CRUD the Service. | ||
OwningGatewayNamespaceLabel = "gateway.envoyproxy.io/owning-gateway-namespace" |
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.
Doesn't the infra correspond to a GatewayClass, which could have >1 Gateways? I would think these labels should identify the GatewayClass.
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.
@skriss since a Gateway supports multiple addresses, each Gateway corresponds to a Service. Therefore, a Service name is constructed as envoy-${GW_NAME}-${GW_NS}
, where the variables are derived from these labels.
The owning Gateway labels are required so the gateway controller can reconcile the appropriate Gateway from CRUD's of a watched Service. As you know, we need to watch the Envoy service to get the status.ingresses[].ip
to populate gateway.status.addresses
.
Added |
2cf81ce
to
8d71f6f
Compare
@danehans curious if this PR unblocks the first few GatewayAPI conformance tests |
Signed-off-by: danehans <daneyonhansen@gmail.com>
@arkodg I have not looked into the tests so I'm unsure. From our discussions during the last few community meetings, I do know this PR will unblock our ability to run conformance tests. This is becasue the test client uses |
cool, would be great if you can attach the Gateway output highlighting the updated status with the LB address, TIA |
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.
Mostly LGTM, one nit. I'm a bit unclear on what's going on with labels -- if we have a single service per GatewayClass, wouldn't we want to label the Service with the GatewayClass info? https://github.com/envoyproxy/gateway/blob/main/internal/gatewayapi/translator.go#L114-L121 appears to only keep labels for the last Gateway that's seen since it's continually overwriting them for each Gateway, which seems weird. In the end I'm not sure how much it matters, since for every Reconcile call we're reconciling everything, and not actually using the service's labels to look up the relevant service for a Gateway, but it may be confusing.
Signed-off-by: danehans <daneyonhansen@gmail.com>
@skriss thanks for the review. I have refactored the PR to use a GatewayClass owning label. The service watch event handler of the gateway controller now looks for the GatewayClass owning label. If found, it will load all the Gateways from the resource map and create a reconcile request for each Gateway that references a GatewayClass that matches the owning label. |
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 makes sense to me based on the current relationship between GatewayClass and infra/a Service, can always revisit if/when needed.
labels.go
.Requires #350
Fixes #330