Copy the current OpenCensus protos. #134

bogdandrutu · 2019-04-17T02:40:29Z

This PR only modifies the packages, copyright and authors from the initial files.
Follow up PRs will update the protos in order to keep a history.
In the final state the protos will be moved to a different repo and a Java artifact will be generated from there, but for the moment we keep them here.

SergeyKanzhelev

So you need a sign off on copy of files, all the modifications will come later, correct?

@SergeyKanzhelev

…received This is considered an bug in the spec that was uncovered in the discussion here: open-telemetry#442 (comment) I did some spelunking and the "generate" recommendation comes from the very first commit: open-telemetry@b5bcfff#diff-ef5f80fbf835dd57e14cb9264944f03d80cf6b04cc7671b0e7fb33167c67efcc where they were copied from Java repo, to which they were copied from OpenCensus open-telemetry/opentelemetry-java#134 and in OpenCensus the wording first time appeared here census-instrumentation/opencensus-proto#160 (authored by @SergeyKanzhelev, merged by @bogdandrutu). We are deleting the requirement to generate a new trace id or span id if an invalid id is received. The receivers can decide how they want to treat the invalid id (just like upon receiving any other invalid id), e.g. they may drop it, log an error, accept the invalid data, etc. We are not going to prescribe a particular receiver behavior when invalid trace/span id is received.

@SergeyKanzhelev

…received (#444) This is considered an bug in the spec that was uncovered in the discussion here: #442 (comment) I did some spelunking and the "generate" recommendation comes from the very first commit: b5bcfff#diff-ef5f80fbf835dd57e14cb9264944f03d80cf6b04cc7671b0e7fb33167c67efcc where they were copied from Java repo, to which they were copied from OpenCensus open-telemetry/opentelemetry-java#134 and in OpenCensus the wording first time appeared here census-instrumentation/opencensus-proto#160 (authored by @SergeyKanzhelev, merged by @bogdandrutu). We are deleting the requirement to generate a new trace id or span id if an invalid id is received. The receivers can decide how they want to treat the invalid id (just like upon receiving any other invalid id), e.g. they may drop it, log an error, accept the invalid data, etc. We are not going to prescribe a particular receiver behavior when invalid trace/span id is received.

@SergeyKanzhelev

…received (open-telemetry#444) This is considered an bug in the spec that was uncovered in the discussion here: open-telemetry#442 (comment) I did some spelunking and the "generate" recommendation comes from the very first commit: open-telemetry@b5bcfff#diff-ef5f80fbf835dd57e14cb9264944f03d80cf6b04cc7671b0e7fb33167c67efcc where they were copied from Java repo, to which they were copied from OpenCensus open-telemetry/opentelemetry-java#134 and in OpenCensus the wording first time appeared here census-instrumentation/opencensus-proto#160 (authored by @SergeyKanzhelev, merged by @bogdandrutu). We are deleting the requirement to generate a new trace id or span id if an invalid id is received. The receivers can decide how they want to treat the invalid id (just like upon receiving any other invalid id), e.g. they may drop it, log an error, accept the invalid data, etc. We are not going to prescribe a particular receiver behavior when invalid trace/span id is received.

@SergeyKanzhelev

…received (open-telemetry#444) This is considered an bug in the spec that was uncovered in the discussion here: open-telemetry#442 (comment) I did some spelunking and the "generate" recommendation comes from the very first commit: open-telemetry@b5bcfff#diff-ef5f80fbf835dd57e14cb9264944f03d80cf6b04cc7671b0e7fb33167c67efcc where they were copied from Java repo, to which they were copied from OpenCensus open-telemetry/opentelemetry-java#134 and in OpenCensus the wording first time appeared here census-instrumentation/opencensus-proto#160 (authored by @SergeyKanzhelev, merged by @bogdandrutu). We are deleting the requirement to generate a new trace id or span id if an invalid id is received. The receivers can decide how they want to treat the invalid id (just like upon receiving any other invalid id), e.g. they may drop it, log an error, accept the invalid data, etc. We are not going to prescribe a particular receiver behavior when invalid trace/span id is received.

@SergeyKanzhelev

…received (open-telemetry#444) This is considered an bug in the spec that was uncovered in the discussion here: open-telemetry#442 (comment) I did some spelunking and the "generate" recommendation comes from the very first commit: open-telemetry@b5bcfff#diff-ef5f80fbf835dd57e14cb9264944f03d80cf6b04cc7671b0e7fb33167c67efcc where they were copied from Java repo, to which they were copied from OpenCensus open-telemetry/opentelemetry-java#134 and in OpenCensus the wording first time appeared here census-instrumentation/opencensus-proto#160 (authored by @SergeyKanzhelev, merged by @bogdandrutu). We are deleting the requirement to generate a new trace id or span id if an invalid id is received. The receivers can decide how they want to treat the invalid id (just like upon receiving any other invalid id), e.g. they may drop it, log an error, accept the invalid data, etc. We are not going to prescribe a particular receiver behavior when invalid trace/span id is received.

@SergeyKanzhelev

…received (open-telemetry#444) This is considered an bug in the spec that was uncovered in the discussion here: open-telemetry#442 (comment) I did some spelunking and the "generate" recommendation comes from the very first commit: open-telemetry@b5bcfff#diff-ef5f80fbf835dd57e14cb9264944f03d80cf6b04cc7671b0e7fb33167c67efcc where they were copied from Java repo, to which they were copied from OpenCensus open-telemetry/opentelemetry-java#134 and in OpenCensus the wording first time appeared here census-instrumentation/opencensus-proto#160 (authored by @SergeyKanzhelev, merged by @bogdandrutu). We are deleting the requirement to generate a new trace id or span id if an invalid id is received. The receivers can decide how they want to treat the invalid id (just like upon receiving any other invalid id), e.g. they may drop it, log an error, accept the invalid data, etc. We are not going to prescribe a particular receiver behavior when invalid trace/span id is received.

bogdandrutu requested review from carlosalberto, SergeyKanzhelev and yurishkuro as code owners April 17, 2019 02:40

SergeyKanzhelev approved these changes Apr 17, 2019

View reviewed changes

bogdandrutu force-pushed the protos branch 3 times, most recently from 936d9b9 to 5f3ab17 Compare April 17, 2019 20:22

bogdandrutu added 3 commits April 17, 2019 13:51

Copy the current OpenCensus protos.

04e7ef1

Update protobuf and grpc

7f82a40

Remove jmh.

c600cb4

bogdandrutu force-pushed the protos branch from c2a5192 to c600cb4 Compare April 17, 2019 20:58

bogdandrutu merged commit 6928ae2 into master Apr 17, 2019

bogdandrutu deleted the protos branch April 17, 2019 21:07

bogdandrutu mentioned this pull request Apr 17, 2019

Cleanup copyright and package. #149

Merged

tigrannajaryan mentioned this pull request Jan 10, 2023

Clarify behavior for empty/not present/invalid trace_id and span_id fields open-telemetry/opentelemetry-proto#442

Merged

tigrannajaryan mentioned this pull request Jan 10, 2023

Delete requirement to generate new trace/span id if an invalid id is received open-telemetry/opentelemetry-proto#444

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Copy the current OpenCensus protos. #134

Copy the current OpenCensus protos. #134

bogdandrutu commented Apr 17, 2019

SergeyKanzhelev left a comment

Copy the current OpenCensus protos. #134

Copy the current OpenCensus protos. #134

Conversation

bogdandrutu commented Apr 17, 2019

SergeyKanzhelev left a comment

Choose a reason for hiding this comment