Rename old env variables that use TRACE_ with TRACES_

[bogdandrutu]

Signed-off-by: Bogdan Drutu bogdandrutu@gmail.com

Follow-up after #1362

[Oberon00]

Sorry, but OTEL_TRACES_SAMPLER sounds very unnatural. Are we sure we don't want to go the other way round and use TRACE_ everywhere? EDIT: Same with METRICS_EXPORTER vs METRIC_EXPORTER: Singular sounds more natural (and is one letter shorter 😃)

[bogdandrutu]

@Oberon00 :))

[carlosalberto]

Thanks for the catch! Was wondering whether we had forgotten something or not :)

Are we sure we don't want to go the other way round and use TRACE_ everywhere?

Not a strong opinion from me, as long as we stick to one or the another. I doubt there will be a perfect solution :/

[Oberon00]

Since this PR is already by definition a bike-shedding discussion, I don't feel about making this a "Request changes": I strongly object to the plural form, which sounds like bad English to me. If we want consistency we should go with singular (both TRACE_ and METRIC_) everywhere.

[carlosalberto]

I strongly object to the plural form

@tigrannajaryan Any opinion on this? You were a big supporter of the plural as (IIRC) that's what is used in the Collector.

(I'm fine either way, btw)

[tigrannajaryan]

The reason I suggest to use plural is we have a lot of code in Collector that uses plural which is also a public API of the Collector. If we were to change it then it will be a breaking change for third parties that rely on it (we are Beta - so formally we are allowed to do it). Plural form is also used in Collector config files, so it will be a breaking change for end users as well.

Changing back to singular is at least inconvenience for third-party people who we will break. IMO, it is not worth it.

Singular sounds more natural (and is one letter shorter 😃)
I strongly object to the plural form, which sounds like bad English to me

@Oberon00 to be fair, none of what you listed seems like a good enough justification to me. I may be wrong.

[Oberon00]

OK, fair enough. But then isn't leaving everything as it is a good option as well?

For practical reasons, it is already too much effort to rename the older enviornment variables.

[carlosalberto]

But then isn't leaving everything as it is a good option as well?

Well, we already had a few mismatches here and there (METRIC vs METRICS and SPAN vs TRACE) :( So sadly we had to change things one way or another. Oh well...

[andrewhsu]

LGTM (after conflict resolved in CHANGELOG.md)

[tigrannajaryan]

OK, fair enough. But then isn't leaving everything as it is a good option as well?

I think we should aim for consistency and use plural "everywhere". Unfortunately "everywhere" is not really 100% everywhere; a couple places in OTLP proto declarations we cannot touch because it will break the proto. But vast majority of Otel spec and code can use plural. Today it is a mix of plural and singular depending on the repo or are of work.

[jkwatson]

I don't like the plurals, and this will break every language SDK out there, correct? So, we fix the collector, or we force all language maintainers to change? Seems like changing in one place (the collector) would be a much smaller impact.

[tigrannajaryan]

I don't like the plurals, and this will break every language SDK out there, correct? So, we fix the collector, or we force all language maintainers to change? Seems like changing in one place (the collector) would be a much smaller impact.

I would risk and guess that very little real users currently depend on SDK's env variable today as opposed to many users actually using Collector in production and a large number of developers . So the impact is not really smaller, it is bigger if we touch the Collector. Again, I may be wrong, I am probably not aware of production uses of SDKs, happy to be corrected.

I do not mind doing the work and renaming everything in the Collector (it is easy to do) but the implications of the change I think are too big to do it.

If we are not able to agree on a breaking change then this needs to be handled gracefully by supporting both plural and singular for a while (highly undesirable and a lot of extra work).

[Oberon00]

How about supporting both plural and singular in the collector? Shouldn't be hard to implement either.

[carlosalberto]

I don't like the plurals, and this will break every language SDK out there, correct?

Well, sadly we already broke them by renaming a few other things from _SPAN_ to _TRACES_, so this already happened 😢

How about supporting both plural and singular in the collector? Shouldn't be hard to implement either.

That's just avoiding the problem IMHO 😅

I personally suggest sticking to _TRACES_ as originally discussed recently, even if it's an imperfect solution.

[Oberon00]

That's (in a way 😉 ) solving the problem. Only the singular would be spec'd and documented, and existing collector user's config continues to work. Language SDKs are free to do the same thing, or just support the final name.

[tigrannajaryan]

I don't like the plurals, and this will break every language SDK out there, correct?

Well, sadly we already broke them by renaming a few other things from _SPAN_ to _TRACES_, so this already happened 😢

This is a good point. Since we already did this and this needs to be done regardless of plural/singular debate I think there is no point worrying about breaking SDKs anymore. SDKs are already broken. I do not see why we should also break the Collector.

[tigrannajaryan]

That's (in a way 😉 ) solving the problem. Only the singular would be spec'd and documented, and existing collector user's config continues to work. Language SDKs are free to do the same thing, or just support the final name.

I don't understand what is solving the problem. Please clarify.

[Oberon00]

I meant supporting both the previously existing plural names and the (hypothetical) new singular names. #1382 (comment)

[trask]

I don't like the plurals

fwiw, the plural env var names (OTEL_TRACES_EXPORTER, OTEL_TRACES_SAMPLER) feel awkward to me also

[iNikem]

As a foreign language speaker both plural and singular are the same to me :) Thus consistency wins.

[jsuereth]

Is the churn caused to collector users really necessary here? If we discover issues like this post 1.0 what's the plan then?

I understand a desire for consistency, but in this case I think it is affecting real users. I'd like to echo @tigrannajaryan here. We need to be far more careful of changes NOW if we really want our 1.0 to be stable. This is exactly the kind of churn that can cause delays for minimal gain. I'd like to understand the plan for how to handle this kind of inconsistency post 1.0.

Why not allow both variables with a migration period so there's no IMMEDIATE churn.

[carlosalberto]

Why not allow both variables with a migration period so there's no IMMEDIATE churn.

We already broke them for the SDKs by renaming a few inconsistencies already, i.e. OTEL_EXPORTER becoming OTEL_TRACE_EXPORTER and OTEL_METRICS_EXPORTER. So changing them IMHO it's ok but we need to make sure that whatever we choose stays stable (just to be on the safe side).

@tigrannajaryan Are there any environment variable that uses TRACES in the collector? IIRC we only use traces for a config like

  pipelines:
    traces:
      receivers: [otlp, opencensus, jaeger, zipkin]

So I'm personally fine with the Collector using traces (as a single word) and all the environment variables in the API/SDK using _TRACE_ instead.

[tigrannajaryan]

@tigrannajaryan Are there any environment variable that uses TRACES in the collector?

No, there is none in the Collector.

[carlosalberto]

Based on today's conversation at the Maintainers meeting call, I'd strongly suggest to go with TRACES even if it feels ugly in some cases/combinations, in order to go dead simple and have the same plural traces everywhere (and, hopefully, we finally reach stability for env variables).

In that regard, we do have enough approvals already, btw ;)

cc @jsuereth

[jsuereth]

@carlosalberto I think my point on stability was well discussed. Given the consideration, and the desire to still merge this, that's ok. Hopefully we'll change future behavior in this regard, and I think the right discussions have kicked off. Don't hold off on this for me :)