api: promote tracing operation to listener level#7723
api: promote tracing operation to listener level#7723htuch merged 5 commits intoenvoyproxy:masterfrom
Conversation
|
I am not a fan of using the default value 0 to mean INGRESS, but alas, the API needs to stay backwards compatible. I'd like to add a third option to mean undefined/middle proxy, but that requires plumbing through all tracers. |
3814dc4 to
fb24859
Compare
Signed-off-by: Kuat Yessenov <kuat@google.com>
fb24859 to
fb1c733
Compare
snowp
left a comment
There was a problem hiding this comment.
Seems reasonable to me, just one comment on the V1 JSON handling
source/common/config/filter_json.cc
Outdated
| envoy::config::filter::network::http_connection_manager::v2::HttpConnectionManager::Tracing:: | ||
| OperationName_Parse(StringUtil::toUpper(json_tracing->getString("operation_name")), | ||
| &operation_name); | ||
| envoy::api::v2::core::TracingOperation operation_name{}; |
There was a problem hiding this comment.
I don't think we need this change since this is for the deprecated V1 config handling
There was a problem hiding this comment.
I renamed the proto enum, so this is necessary for build to complete. It has no effect on the wire, since it's the same enum structurally.
|
cc @htuch for UDPA visibility / compatibility, this breaks generated code as well. |
|
I'm fine putting HTTP thingy where it belonged and duplicating the proto. I just think this is less sustainable long-term. |
api/envoy/config/filter/network/http_connection_manager/v2/http_connection_manager.proto
Show resolved
Hide resolved
|
@kyessenov Just wondering if this is a good opportunity to change the concept from "operation" to what it truly represents, i.e. "direction"? Operation can be misleading, as it can also refer to the "operation" being performed on the service. |
|
Waiting for @htuch to take a look from the API perspective. /wait-any |
|
@objectiser I'm happy to pick a better name. Tracing direction? Traffic direction? Direction? |
Signed-off-by: Kuat Yessenov <kuat@google.com>
|
@htuch undid changes to HTTP tracing and added a TODO to align it later. |
|
@kyessenov traffic direction LGTM. |
|
OK, so this is now good from an API compat standpoint, but I'm questioning why we need this. Can't you use LDS metadata for direction? I'm wondering how universal the notion of ingress/egress is here vs. something that is Istio specific? Envoy is used in a ton of configurations, including edge and middle proxy, so ingress/egress doesn't really capture these, in particular when there is no local application. How do we deal with these? |
|
@htuch Ingress/egress is used in all HTTP tracers' configurations, so I think it's fairly common apart from istio as well. The issue with middle proxies is a real one, and I don't have a good answer here apart from adding a new enum value to model it. The question should be how would you model a middle proxy in the existing HTTP tracer config, and we can incorporate the answer into this new config. |
|
@kyessenov OK. Can you open an issue for that? Also, needs master merge. Otherwise, LGTM. |
mattklein123
left a comment
There was a problem hiding this comment.
Please add a config test for this field on the listener, otherwise LGTM. Thank you!
/wait
Signed-off-by: Kuat Yessenov <kuat@google.com>
|
/retest |
|
🔨 rebuilding |
|
/retest |
|
🐴 hold your horses - no failures detected, yet. |
|
/retest |
|
🐴 hold your horses - no failures detected, yet. |
|
/azp run |
|
Commenter does not have sufficient privileges for PR 7723 in repo envoyproxy/envoy |
Signed-off-by: Kuat Yessenov kuat@google.com
Description:
Promote tracing operation field to listener level. This expands the scope of the field to support two use cases:
Risk Level: low
Testing: all unit tests continue to pass
Docs Changes:
Release Notes: