-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
opentelemetrytracer: Dynatrace sampler: Use http_service in configura… #33034
opentelemetrytracer: Dynatrace sampler: Use http_service in configura… #33034
Conversation
…tion. (#22) * change dynatrace sampler config to use http_service Signed-off-by: thomas.ebner <[email protected]> Signed-off-by: Thomas Ebner <[email protected]> Co-authored-by: Joao Grassi <[email protected]>
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
…ce-to-configure-dynatrace-sampler Signed-off-by: thomas.ebner <[email protected]>
Signed-off-by: thomas.ebner <[email protected]>
Signed-off-by: thomas.ebner <[email protected]>
Signed-off-by: thomas.ebner <[email protected]>
Signed-off-by: thomas.ebner <[email protected]>
Signed-off-by: thomas.ebner <[email protected]>
Signed-off-by: thomas.ebner <[email protected]>
#32598 was merged at three weeks ago. So you cannot change the proto API in that way directly. /wait |
@wbpcode oh really? Even though this isn't released yet? Is there anything we should do, like force the change or smt? |
@envoyproxy/api-shepherds |
I think you have missed the time window. |
api/envoy/extensions/tracers/opentelemetry/samplers/v3/dynatrace_sampler.proto
Show resolved
Hide resolved
api/envoy/extensions/tracers/opentelemetry/samplers/v3/dynatrace_sampler.proto
Show resolved
Hide resolved
field. Signed-off-by: thomas.ebner <[email protected]>
api/envoy/extensions/tracers/opentelemetry/samplers/v3/dynatrace_sampler.proto
Outdated
Show resolved
Hide resolved
source/extensions/tracers/opentelemetry/samplers/dynatrace/sampler_config_provider.cc
Show resolved
Hide resolved
What does "Since the Dynatrace sampler is not yet released it should be ok to do config breaking change." mean here? Generally we operate on the principle that HEAD is always a release candidate and shoudl abide by principle described by @wbpcode. That said, if for some reason there is 0% chance someone might be sensibly ysing Dynatrace (e.g. the implementation was not fully completed and this is a a brand new extension), maybe there is an ability to introduce an exception here. As soon as someone can reasonably be using this feature and the 14 day window expires, we need to follow proper API stability protocol though. |
@htuch yeah unfortunately we weren't aware that HEAD is a release candidate and about the 14 day window for changes so we thought since it isn't released yet it would be OK to make such changes.
@htuch from the Dynatrace side, we can be certain that this is not used. We are not finished in the Dynatrace cluster side to make this work (configuration endpoint that this extension requires and polls from is only going to be GA in some weeks). Also, the work to enable and use this in Istio is also not merged istio/api#3134 and we never announced/promoted this to any customer of ours. Also yes, this is a new extension that we added exactly a month ago #32598 We have done the code changes to still keep the "old" API and handle it in code but we would really appreciate if we could avoid this, since it just adds complexity in code/more tests for something that nobody would ever use. Maybe we can reconsider? Apologies for the odd situation here. |
Ack. I think we can make an exception here then, @wbpcode @envoyproxy/api-shepherds please raise any concerns on allowing a breaking change out of the window given the context in #33034 (comment) |
I am OK to make it an exception. :) |
… a new" This reverts commit cec4b0f. Signed-off-by: thomas.ebner <[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.
Thanks, I have reverted cec4b0f where I started to add handling for the old config.
api/envoy/extensions/tracers/opentelemetry/samplers/v3/dynatrace_sampler.proto
Show resolved
Hide resolved
message->headers().setReference(Http::CustomHeaders::get().Authorization, | ||
authorization_header_value_); | ||
for (const auto& header_pair : parsed_headers_to_add_) { | ||
message->headers().setReference(header_pair.first, header_pair.second); | ||
} |
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 overall except this one. Basically, we think the token or passwd should be kept in secret. And if an raw string is used then we should mark it as sensitive
and the config_dump
will hide it when dump all the configurations.
So, if you use the request_headers_to_add
, the token may be exposed in the dumped configuration file.
If you think it's OK, then I am also OK to this design.
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.
Thank's for the hint. I have discussed this with @joaopgrassi. We are aware of the problem but we would like to keep it as is for now. We would have to add the [(udpa.annotations.sensitive) = true]
annotation to the http_service
field. This would make it very hard to debug a wrong config.
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.
My suggestion is to keep the token
in another independent field and mark it as sensitive
. But if you guys think the current implementation is OK. Then I am happy to approve.
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.
Waiting your last confirmation, then I will merge this PR.
/wait-any
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.
@wbpcode We have discussed internally and we prefer to keep it as is. We already have the same situation in the HTTP exporter, where the token is also passed/used in the http headers, so we prefer to keep the config consistent to not confuse users. It also makes the Istio part of the configuration easier, because we can then re-use the headers of the HTTP exporter for the sampler, as in 99% of the cases they will be configured together by customers (http exporter + Dynatrace sampler).
/lgtm |
please specify a single label can be specified |
envoyproxy#33034) * opentelemetrytracer: Dynatrace sampler: Use http_service in configuration. (#22) * change dynatrace sampler config to use http_service Signed-off-by: thomas.ebner <[email protected]> Signed-off-by: Thomas Ebner <[email protected]> Co-authored-by: Joao Grassi <[email protected]> * modify protobuf doc Signed-off-by: thomas.ebner <[email protected]> * remove empty line in proto file Signed-off-by: thomas.ebner <[email protected]> * added empty line in proto file Signed-off-by: thomas.ebner <[email protected]> * try to fix "Error in "code-block" directive" Signed-off-by: thomas.ebner <[email protected]> * fix "Error in "code-block" directive" Signed-off-by: thomas.ebner <[email protected]> * change proto documentation again Signed-off-by: thomas.ebner <[email protected]> * review feedback: keep unused values marked as deprecated. Add a new field. Signed-off-by: thomas.ebner <[email protected]> * Revert "review feedback: keep unused values marked as deprecated. Add a new" This reverts commit cec4b0f. Signed-off-by: thomas.ebner <[email protected]> --------- Signed-off-by: thomas.ebner <[email protected]> Signed-off-by: Thomas Ebner <[email protected]> Co-authored-by: Joao Grassi <[email protected]>
Commit Message: change Dynatrace sampler config to use http_service
Additional Description: In #32598 a custom Dynatrace sampler was added to Envoy. This sampler fetches its configuration via an HTTP call from a Dynatrace cluster. The endpoint and some additional information required to perform the HTTP call can be set in the Envoy config file.
While working on Istio changes to allow to set the endpoint, it turned out that it would be easier to use
http_service
instead ofhttp_uri
.This also allows to configure additional HTTP headers which are added to the request.
Another benefit is that the configuration is now aligned to the HTTP exporter, see https://github.com/envoyproxy/envoy/blob/main/api/envoy/config/trace/v3/opentelemetry.proto#L42
Since the Dynatrace sampler is not yet released it should be ok to do config breaking change.
Risk Level: LOW
Testing: Unit, Integration, Manual
Docs Changes: N/A
Release Notes: N/A
Platform Specific Features: N/A
[Optional Runtime guard:] N/A
[Optional Fixes #Issue] N/A
[Optional Fixes commit #PR or SHA] #32598, #32848
[Optional Deprecated:] N/A
[Optional API Considerations:] N/A