-
Notifications
You must be signed in to change notification settings - Fork 299
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
feat(translator): xds route and vhost metadata #3602
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #3602 +/- ##
==========================================
+ Coverage 68.81% 68.97% +0.16%
==========================================
Files 175 176 +1
Lines 21524 21610 +86
==========================================
+ Hits 14811 14906 +95
+ Misses 5636 5628 -8
+ Partials 1077 1076 -1 ☔ View full report in Codecov by Sentry. |
Signed-off-by: Guy Daich <[email protected]>
Signed-off-by: Guy Daich <[email protected]>
/retest |
@@ -1082,6 +1082,13 @@ xds: | |||
routes: | |||
- match: | |||
prefix: / | |||
metadata: | |||
filterMetadata: | |||
io.envoyproxy.gateway.metadata: |
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.
Would we need to add other metadata in the future? If so, we might need another level within the metadata structure to accommodate them.
This may look like:
io.envoyproxy.gateway.metadata:
HTTPRoute:
name: backend
namespace: default
Gateway:
name: foo
namespace: bar
xxxx:
.....
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 changed the field to be a list of resources for future proofing.
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.
Actually, I'm having second thoughts about a list here. It's not so easy to address metadata in a list. So, I think that I'll go with your approach, but maybe slightly generalize to Gateway
, Route
and Backend
top-level resources, which can then be GW/GWC, HTTP/GRPCRoute, Service/ServiceImport/Backend.
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 just thought the metadata structure should be able to accommodate multiple resources, but I don't know how exactly the structure should look like either. Let's brainstorm in the next meeting?
@@ -1082,6 +1082,13 @@ xds: | |||
routes: | |||
- match: | |||
prefix: / | |||
metadata: | |||
filterMetadata: | |||
io.envoyproxy.gateway.metadata: |
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.
metadata.filterMetadata.io.envoyproxy.gateway.metadata
seems a bit redundant, maybe just useio.envoyproxy.gateway
as the key?
Signed-off-by: Guy Daich <[email protected]>
Signed-off-by: Guy Daich <[email protected]>
Signed-off-by: Guy Daich <[email protected]>
- [TCP/UDPRoute][tcpr] and [TLSRoute][tlsr] resource attributes are not propagated. These resources are translated to envoy filter chains, which do not currently support static metadata. | ||
- [Service][svc], [ServiceImport][svci] and [Backend][] metadata and port name are propagated to envoy [cluster] metadata. | ||
|
||
## Usage |
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.
about usgae
, can we also highlight this in the https://gateway.envoyproxy.io/latest/tasks/observability/proxy-observability/#logs ?
Signed-off-by: Guy Daich <[email protected]>
Signed-off-by: Guy Daich <[email protected]>
/retest |
1 similar comment
/retest |
|
||
// ResourceMetadata is metadata from the provider resource that is translated to an envoy resource | ||
// +k8s:deepcopy-gen=true | ||
type ResourceMetadata struct { |
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.
thoughts on leaving out SectionName
and GroupVersion
in the first iteration ?
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.
will remove GroupVersion
. I'll add VHost to this PR in a bit, and it'll include a useful SectionName
, so prefer to keep it.
internal/xds/translator/route.go
Outdated
retryDefaultRetryOn = "connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes" | ||
retryDefaultRetriableStatusCode = 503 | ||
retryDefaultNumRetries = 2 | ||
envoyGatewayMetadataNamespace = "io.envoyproxy.gateway" |
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.
should this be envoy-gateway
instead ?
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.
Several parts of Envoy configuration (e.g. listeners, routes, clusters) contain a metadata where arbitrary key-value pairs can be encoded. The typical pattern is to use the filter names in reverse DNS format as the key and encode filter specific configuration metadata in the value.
However, I agree that:
- There is no filter in this case, so, we're not bound by these conventions. Istio uses a namespace called
istio
(and notio.istio
) for similar purposes. - the long name is not convenient for access log formatters accessing the relevant keys.
internal/xds/translator/route.go
Outdated
envoyGatewayMetadataKeyNamespace = "namespace" | ||
envoyGatewayMetadataKeyAnnotations = "annotations" | ||
envoyGatewayMetadataKeySectionName = "sectionName" | ||
envoyGatewayMetadataKeyRoute = "route" |
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.
to which resource are we building this key off ? input gateway api, IR or xds filter ?
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.
will change to envoyGatewayXds*
to make it clear that this is a const used in generated XDS.
/retest |
2 similar comments
/retest |
/retest |
Also fine with allowing users to add this if needed. |
/retest |
1 similar comment
/retest |
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.
LGTM. This can be extremely helpful for EG users when debugging. I strongly suggest adding the metadata to the default log format - hiding this information by default is a huge waste.
@@ -31,6 +31,8 @@ const ( | |||
// Request timeout, which is defined as Duration, specifies the upstream timeout for the route | |||
// If not specified, the default is 15s | |||
HTTPRequestTimeout = "15s" | |||
// egPrefix is a prefix of annotation keys that are processed by Envoy Gateway |
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.
unused ?
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.
used in filterEGPrefix
to filter the annotations that should be picked up for metadata.
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.
how do we document this opt in behavior ? user guide ?
internal/xds/translator/metadata.go
Outdated
envoyGatewayXdsMetadataKeyNamespace = "namespace" | ||
envoyGatewayXdsMetadataKeyAnnotations = "annotations" | ||
envoyGatewayXdsMetadataKeySectionName = "sectionName" | ||
envoyGatewayXdsMetadataKeyRoute = "route" |
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.
why are these keys needed ?
as a consumer I may want to access the envoy-gateway
metadata, but I may not know if the xds resource maps to a gateway
or route
or both
Signed-off-by: Guy Daich <[email protected]>
Signed-off-by: Guy Daich <[email protected]>
Signed-off-by: Guy Daich <[email protected]>
Sorry for force-push, I messed up the recent commit. We will go with the list approach, since it's most future proof, considering situations where multiple resources of the same kind (e.g. policy and overriding policy) can contribute metadata. Since there's currently no convenient way to reference a specific member of a list in envoy formatter at the moment, I prefer to leave metadata out of the default access log format, and not log all metadata by default. |
out := map[string]string{} | ||
for k, v := range in { | ||
if strings.HasPrefix(k, egPrefix) { | ||
out[strings.TrimPrefix(k, egPrefix)] = v |
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.
should we trim the prefix or let it 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.
It feels a bit redundant to me, since only annotations with this prefix will be included.
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.
cool, lets leave as is
Signed-off-by: Guy Daich <[email protected]>
Signed-off-by: Guy Daich <[email protected]>
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.
LGTM thanks !
super excited to use this feature
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.
🚀
What this PR does / why we need it:
HTTPRoute
/GRPCRoute
metadata to envoy route resourcesGateway
andListener
to Virtual Host metadataWhich issue(s) this PR fixes:
Relates to #3318