opentelemetry-proto
opentelemetry-proto copied to clipboard
open-telemetry
Add missing trace flags to Span and Link messages
I now wonder if the otlp messages should also contain the w3c version so when more flags are added in the future, the receiver can differentiate between them being set to "0" vs "not set" by examining the version. Any thoughts? @dyladan
@blumamir I think we can add the version when w3c changes to v2, before that, the absence of the version means version 1.
@blumamir I think we can add the version when w3c changes to v2, before that, the absence of the version means version 1.
If we add it when w3c bump the version, then all existing exporters out there will not report it which will be interpreted as 0 and we are back to the original backward support problem that we are now facing.
It means that a processor will not be able to use a new flag until all the exporters in production are upgraded to a version that supports the new proto release with the w3c version field, which can be a long and painful process.
It means that a processor will not be able to use a new flag until all the exporters in production are upgraded to a version that supports the new proto release with the w3c version field, which can be a long and painful process.
Isn't that true anyway? Let's assume we add the field and everyone just exports "v=1", what is the difference?
Should we maybe wait a bit with this and do it together with IsRemote once https://github.com/open-telemetry/oteps/pull/182 is merged, to minimize the chance of inconsistencies?
Should we maybe wait a bit with this and do it together with IsRemote once open-telemetry/oteps#182 is merged, to minimize the chance of inconsistencies?
We can wait. If it is delayed for a long time we can also move forward with this since I think we can add new flags in backward compatible manner. For IsRemote we likely will need 2 bits to represent (Unspecified=00, IsRemote=01, IsNotRemote=01) state. Unspecified will be the default state matching the zero state of the field (which will make it backward compatible with existing OTLP versions).
https://github.com/open-telemetry/oteps/pull/182 has not seen much progress. Do we want to move forward with this PR?
Closing this in favor of #503. The purpose is identical, but we believe @blumamir is no longer focused on OTel so I will carry this out.
@blumamir was on a break for a while but is back and active in otel again. I'm sure he probably doesn't mind work being consolidated into #503 though
