telemetry: support lightstep removal and otel addition for envoy tracing

[douglas-reid]

Envoy has dropped support for the custom Lightstep tracer extension. In the associated PRs, the Lightstep team stated that the path forward is the newly-added OpenTelemetry tracer extension. This PR attempts to appropriately deprecate Lightstep configuration and add a provider for OpenTelemetry (so that it can be exploited by the Telemetry API).

Full issue (for discussion): istio/istio#40027

[istio-testing]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[istio-policy-bot]

😊 Welcome @douglas-reid! This is either your first contribution to the Istio api repo, or it's been
awhile since you've been here.

You can learn more about the Istio working groups, code of conduct, and contributing guidelines
by referring to Contributing to Istio.

Thanks for contributing!

Courtesy of your friendly welcome wagon.

[howardjohn]

Seems reasonable to me

[zirain]

any special reason for this line?

[douglas-reid]

I think we can "safely" transition to OTel provider for service + port, but there is no similar concept of access token. That would mean ignoring access_token in this configuration, however.. I was thinking it might be useful to have some way of indicating that it would be ignored in generated Envoy configuration moving forward. But I don't feel too strongly here.

[zirain]

does that means in the next release of istio, Lightstep provider is mostly same as OTel provider?

[smithclay]

Hi @douglas-reid, working on documenting the Lightstep tracer -> OTel migration path. The envoy config setting that replaces access_token is a special header key/value pair, here's a sample envoy config:

            provider:
              name: envoy.tracers.opentelemetry
              typed_config:
                "@type": type.googleapis.com/envoy.config.trace.v3.OpenTelemetryConfig
                grpc_service:
                  envoy_grpc:
                    cluster_name: localcollector
                  initial_metadata:
                    - key: lightstep-access-token
                      value: "your-lightstep-access-token"
                service_name: envoy

[douglas-reid]

@smithclay thanks! that's very helpful. whenever you complete the migration guide, we'd really appreciate your sharing it here.

[douglas-reid]

@howardjohn @zirain updated this API PR. removed the deprecation bits, but added comments about the expected behavioral changes in 1.15+. I think this gives us room to generate proxy-version specific configuration through the transition. Thoughts?

[istio-testing]

@douglas-reid: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
release-notes_api	63c2aaa	link	false	/test release-notes_api

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[zirain]

@howardjohn @zirain updated this API PR. removed the deprecation bits, but added comments about the expected behavioral changes in 1.15+. I think this gives us room to generate proxy-version specific configuration through the transition. Thoughts?

we'd better add a warning message in pilot?

[ericvn]

So this is something we need to cherry-pick to release-1.15 as well?

[ericvn]

@douglas-reid I'll leave the prior question about if this needs to be cherry-picked up to you.

[douglas-reid]

@ericvn i think envoy 1.23 maintains lightstep support in its current form, so I think this is OK waiting for 1.16 (and a full release cycle of burn-in). @smithclay is that a correct interpretation?

[smithclay]

Correct, breaking envoy change is in envoy 1.24.0.

Any idea what the propagation mode default is for the Lightstep tracer in the current version of Istio? If it's TRACE_CONTEXT, should be mostly good.