Open phlax opened 1 year ago
cc @moderation @Oberon00 @kyessenov
related to #9958
Before we deprecate existing tracers is it possible to clarify the security posture of OpenTelemetry? https://github.com/envoyproxy/envoy/issues/24672
It would also be cool if envoy could support OpenTelemetry OTLP over HTTP (in addition to the current gRPC) before that, see also https://github.com/envoyproxy/envoy/issues/9958#issuecomment-1240334554
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.
Before we deprecate existing tracers is it possible to clarify the security posture of OpenTelemetry? #24672
The security posture has been changed to unknown
since there the upstream OT repository is frozen.
Hi, just to confirm, in the current main branch, before 1.29 is cut, the hard deprecation will happen where an override is required to still access the functionality?
@RyanTheOptimist @phlax At the moment at Dynatrace we are making plans assuming the hard deprecation is merged in 1.29, can you confirm this is actually planned?
This matters for Dynatrace because we need special handling for the version(s) where the config option causes startup to abort without the deprecation override but OpenTracing is still detectable in the binary. As long as >=1.30 actually has OpenTracing removed completely from the binary, that will be fine, but if that version slips due to not adding a hard deprecation in 1.29 we would need to make adjustments.
@wbpcode do you maybe know anything about the above?
can you confirm this is actually planned?
afaiaa this is planned and i think messaging was sent out to this effect altho i think most likely it will be after 1.29 is cut
@phlax
afaiaa this is planned and i think messaging was sent out to this effect altho i think most likely it will be after 1.29 is cut
Alright so, reading https://www.envoyproxy.io/docs/envoy/latest/configuration/operations/runtime#using-runtime-overrides-for-deprecated-features and https://github.com/envoyproxy/envoy/blob/main/CONTRIBUTING.md#breaking-change-policy I understand the deprecation cycle as follows:
1.28
)disallowed_by_default
annotation (❌ not done yet on main
thus not part of 1.29
)1.30
?)Is my understanding right? If so, that means phase two will be 1.30
and phase three 1.31
?
@joaopgrassi this seems correct to me - but seeing as we are slipping a version can we prioritize adding the deprecation as soon as 1.29 is cut?
but seeing as we are slipping a version can we prioritize adding the deprecation as soon as 1.29 is cut?
@phlax This means then the disallowed_by_default
behavior would only be enforced on 1.30? That seems totally fine. Would be great also for us at Dynatrace and our customers.
i think that is fine, as long as we prioritize the deprecation soon after release
i think that is fine, as long as we prioritize the deprecation soon after release
Sounds good to me!
There has been the intention to remove this lib for some time
There were some issues with the build, but #27400 fixes it for now so we can retain and deprecate properly