-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
docs: remove guidance to use names #21763
Conversation
Signed-off-by: Kuat Yessenov <[email protected]>
Docs for this Pull Request will be rendered here: https://storage.googleapis.com/envoy-pr/21763/docs/index.html The docs are (re-)rendered each time the CI |
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.
Hey @kyessenov, thanks for improving the docs.
Could you clarify if we need to use wellknown names or just have the name match the filter config on the listener when using typed_per_filter_config
which is a map of filter_name->config?
See https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-msg-config-route-v3-route, where for typed_per_filter_config
it says "The key should match the filter name, such as envoy.filters.http.buffer for the HTTP buffer filter".
Signed-off-by: Kuat Yessenov <[email protected]>
This is actually resulting in an issue described in #21759 (comment) |
- Updates Envoy to its latest available version (v1.22.2 for Linux, v1.22.1 for Windows). The latest version includes the latest released security fix. We could not update Envoy previously due to a blocking bug: envoyproxy/envoy#20113 - Updates filter names to custom names as wellknown names are deprecated in Envoy (with 1 exception for the http.rbac filter). Envoy will use the TypeURL in the proto to determine which filter to use instead. Wellknown names are not required and using them is confusing because not all filters are defined in the legacy wellknown pkg (e.g. http.local_ratelimit). See: envoyproxy/envoy#21759 envoyproxy/envoy#21763 envoyproxy/go-control-plane#293 envoyproxy/go-control-plane#552 - Uses the distroless image as the alpine image has been discontinued: envoyproxy/envoy#21758 - Updates tests to use custom filter names - Adds `proto_types.go` to aid dynamic proto resolution for typed configs using `any.Any()`. This helps resolve protos where dynamic resolution is necessary. - Updated Prometheus' ConfigMap to reflect changes to Envoy metrics prefixes Signed-off-by: Shashank Ram <[email protected]>
- Updates Envoy to its latest available version (v1.22.2 for Linux, v1.22.1 for Windows). The latest version includes the latest released security fix. We could not update Envoy previously due to a blocking bug: envoyproxy/envoy#20113 - Updates filter names to custom names as wellknown names are deprecated in Envoy (with 1 exception for the http.rbac filter). Envoy will use the TypeURL in the proto to determine which filter to use instead. Wellknown names are not required and using them is confusing because not all filters are defined in the legacy wellknown pkg (e.g. http.local_ratelimit). See: envoyproxy/envoy#21759 envoyproxy/envoy#21763 envoyproxy/go-control-plane#293 envoyproxy/go-control-plane#552 - Uses the distroless image as the alpine image has been discontinued: envoyproxy/envoy#21758 - Updates tests to use custom filter names - Adds `proto_types.go` to aid dynamic proto resolution for typed configs using `any.Any()`. This helps resolve protos where dynamic resolution is necessary. - Updated Prometheus' ConfigMap to reflect changes to Envoy metrics prefixes Signed-off-by: Shashank Ram <[email protected]>
not sure what the |
@kyessenov wondering what the status is on this one - would be good to update the docs before we cut the next release i think /wait-any |
Signed-off-by: Kuat Yessenov <[email protected]>
Signed-off-by: Kuat Yessenov <[email protected]>
@phlax The empty error in docs was because I removed duplicated pages for filters, see how we have two links for some filters: |
Let's merge this before a release @phlax? |
@phlax Gentle ping. |
hi - apologies - ive been a bit snowed under - ill review tomorrow |
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.
@kyessenov can we add the new type_url where we are removing the old info ?
many of these pages have incorrect config examples (~unrelatedly) so without the type url they are a bit unhelpful
@@ -20,8 +20,6 @@ Following are supported JWT alg: | |||
Configuration | |||
------------- | |||
|
|||
This filter should be configured with the name *envoy.filters.http.jwt_authn*. |
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 one is missing any api link - which leaves the page a bit of a dead end in terms of configuration
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.
Yes, let's put back the type URLs where it's missing. The link is the type URL that should be used generally.
this was incorrect, the names are still required $ git grep "\- name: envoy"
|
@@ -5,7 +5,6 @@ Cache filter | |||
|
|||
* :ref:`v3 API reference <envoy_v3_api_msg_extensions.filters.http.cache.v3.CacheConfig>` | |||
* :ref:`v3 SimpleHTTPCache API reference <envoy_v3_api_msg_extensions.cache.simple_http_cache.v3.SimpleHttpCacheConfig>` | |||
* This filter should be configured with the name ``envoy.filters.http.cache``. |
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.
maybe im not understanding something here
$ envoydev/envoy/examples/cache$ git diff
diff --git a/examples/cache/front-envoy.yaml b/examples/cache/front-envoy.yaml
index b953d1e781..caa0ee8b9f 100644
--- a/examples/cache/front-envoy.yaml
+++ b/examples/cache/front-envoy.yaml
@@ -27,8 +27,7 @@ static_resources:
route:
cluster: service2
http_filters:
- - name: "envoy.filters.http.cache"
- typed_config:
+ - typed_config:
"@type": "type.googleapis.com/envoy.extensions.filters.http.cache.v3.CacheConfig"
typed_config:
"@type": "type.googleapis.com/envoy.extensions.cache.simple_http_cache.v3.SimpleHttpCacheConfig"
$ ./verify.sh
...
front-envoy_1 | [2022-07-13 12:50:15.726][9][critical][main] [source/server/server.cc:117] error initializing configuration '/etc/front-envoy.yaml': Proto constraint validation failed (HttpConnectionManagerValidationError.HttpFilters[0]: embedded message failed validation | caused by HttpFilterValidationError.Name: value length must be at least 1 characters): stat_prefix: "ingress_http"
...
ok i see
diff --git a/examples/cache/front-envoy.yaml b/examples/cache/front-envoy.yaml
index b953d1e781..36bcbcb27b 100644
--- a/examples/cache/front-envoy.yaml
+++ b/examples/cache/front-envoy.yaml
@@ -27,7 +27,7 @@ static_resources:
route:
cluster: service2
http_filters:
- - name: "envoy.filters.http.cache"
+ - name: "my.own.special.filter.name"
typed_config:
"@type": "type.googleapis.com/envoy.extensions.filters.http.cache.v3.CacheConfig"
...works, hmmm
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.
Yes, name is required. The incorrect statement is that it must be the qualified extension name. It can be anything.
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 about instead of just removing the name advice we replace with something like:
At a minimum, this filter must be configured with the following @type
config and a name of your choosing:
http_filters:
- name: "envoy.filters.http.cache"
typed_config:
"@type": "type.googleapis.com/envoy.extensions.filters.http.cache.v3.CacheConfig"
I guess we need to be careful not to imply that the config will be sufficient - but if we can think of the right words i think this would be more useful to end users than just removing the ~incorrect advice
/wait-any |
Signed-off-by: Kuat Yessenov <[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.
thnks for resolving this @kyessenov - i think this is a really helpful update to the docs, lgtm
/retest |
Retrying Azure Pipelines: |
Signed-off-by: Kuat Yessenov [email protected]
Commit Message: make a pass to remove stale suggestion to use filter names.
Risk Level: low
Testing: none
Docs Changes: yes
Release Notes: none
Issue: Fix #21759