Date   

Re: [VOTE] OpenTracing Project Proposal

alexis richardson
 

we have 6 YES votes from TOC



On Tue, Sep 27, 2016 at 1:56 AM, Kenneth Owens (kenowens) via cncf-toc <cncf-toc@...> wrote:

Yes

 

Kenneth Owens
CTO Cloud Native Platforms
Cloud Platforms and Services Group
kenowens@...
Phone: +1 408 424 0872
Mobile: +1 314 591 5708


Cisco.com

   

 

Think before you print. Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

 

 

From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@lists.cncf.io] On Behalf Of Chris Aniszczyk via cncf-toc
Sent: Monday, September 26, 2016 10:48 AM
To: cncf-toc@...
Subject: [cncf-toc] [VOTE] OpenTracing Project Proposal

 

The OpenTracing (http://opentracing.io/) team has iterated on their project proposal to a final one which is ready for voting by TOC members: https://github.com/cncf/toc/pull/15

 

So please vote! The proposal is also embedded below for your convenience:

OpenTracing Proposal

Name of project: OpenTracing

Description: A set of consistent, expressive, vendor-neutral APIs for distributed tracing and context propagation, seeslides for the content we presented to the CNCF TOC.

Sponsor / Advisor from TOC: Bryan Cantrill <bryan@...>

Unique Identifier: opentracing

License: Apache License v2.0

Source control repositories:

Initial Committers:

·         Ben Sigelman (@bensigelman)

·         Yuri Shkuro (@yurishkuro)

·         see the Contributors section for more information

Infrastructure requirements: CI and potentially CNCF Community Cluster access

Issue tracker: global - https://github.com/opentracing/opentracing.github.io/issues and per-platform issues are raised on the per-platform repository’s issues area

Mailing lists

Release methodology and mechanics: Various across platforms

Social media accounts: Twitter: @opentracing

Existing sponsorship: Nothing formal; LightStep occasionally spends small amounts of money (hosting events, etc) on behalf of OpenTracing tech talks and so forth.

External Dependencies

Really very little. The core OpenTracing libraries are facade APIs and thus only bring in dependencies that are needed to describe various function parameters and return values. In some cases there are test harnesses that bring in ubiquitous testing packages. OpenTracing is willing to go through and formally enumerate all of these dependencies, but suffice to say there’s nothing interesting to see and everything is permissively licensed.

Statement on alignment with CNCF mission:

OpenTracing is an open API standard for distributed tracing in applications and OSS packages. Developers with experience building microservices at scale understand the role and importance of distributed tracing: per-process logging and metric monitoring have their place, but neither can reconstruct the elaborate journeys that transactions take as they propagate across a distributed system. Distributed traces are these journeys.

So if distributed tracing is so valuable, why doesn’t everyone do it already? Because tracing instrumentation has been fragmented, syntactically inconsistent, and thus excessively expensive to deploy end-to-end across most cloud-native stacks.

Distributed tracing is challenging because the instrumentation must propagate the tracing context both within and between processes. Accomplishing this involves many distinct pieces in a (micro-)service stack. In particular, tracing context must be passed through:

·         Self-contained OSS services (e.g., NGINX, Cassandra, Redis, etc)

·         OSS packages linked into custom services (e.g., grpc, ORMs, etc)

·         Arbitrary application glue and business logic built around the above

And there’s the rub: It is not reasonable to ask all OSS services and all OSS packages and all application-specific code to use a single tracing vendor; yet, if they don’t share a mechanism for trace description and propagation, the causal chain is broken and the traces are truncated, often to the point of uselessness. We need a single, standard mechanism to describe the behavior of our systems. OpenTracing is that single, standard mechanism.

Regarding CNCF’s charter mission, OpenTracing is specifically concerned with making loosely-coupled [micro]services easier to manage. As such, it is strongly aligned with CNCF and its goal to “significantly increase the overall agility and maintainability of applications” by “[making] technology ubiquitous and easily available through reliable interfaces.” Indeed, OpenTracing and CNCF as a whole mutually benefit one another. (It should be noted that, as it is focused on standard instrumentation more than standard encoding formats, OpenTracing today is most relevant at the application layer; it has few specific opinions about — or strong dependencies on — the container layer or orchestration systems more generally, though service discovery and high-quality tracing are symbiotic.)

Other Contributors:

OpenTracing Semantics Repo (formally the opentracing.github.io docs repo)

·         Ben Sigelman (bensigelman) LightStep

·         Yuri Shkuro (yurishkuro) Uber

·         Dan Kuebrich (dkuebric) AppNeta

·         Ben Cronin (bcronin) LightStep

·         Priyanka Sharma (pritianka) LightStep

·         Dimitrios Kouzis-Loukas (lookfwd) Bloomberg

·         Mck (michaelsembwever) Apache

·         Ivan Fraixedes (ifraixedes)

Github issue/discussion participation:

·         Rodrigo Fonseca (rfonseca) Brown University

·         Colin Patrick McCabe (cmccabe) Cloudera

·         Cagatay Kavukcuoglu (tinkerware) Base60Labs

·         Benjamin Eberlei (beberlei) Qafoo

·         Władysław Bodzek (wladekb)

·         Bogdan Drutu (bogdandrutu) Google

·         Grayson Koonce (breerly) Uber

·         Marcin Grzejszczak (marcingrzejszczak) Zipkin

·         Fabian Lange (CodingFabian) Instana

·         Paul Caporn (drpacman) BBC

·         Ben Sigelman (bensigelman) LightStep

·         Tobias Schottdorf (tschottdorf) Cockroach Labs

·         Yuri Shkuro (yurishkuro) Uber

·         Brandon Gonzales (bg451) Student

·         Josh MacDonald (jmacd)

·         Bas van Beek (basvanbeek)

·         Stephen Gutekanst (slimsag) Sourcegraph

·         Richard Scothern (RichardScothern) Docker

·         Tamir Duberstein (tamird) Cockroach Labs

·         Kris Kowal (kriskowal) (I think Uber)

·         Aleksey (IncSW)

·         Kyle Conroy (kyleconroy) Stripe

·         Blake Mizerany (bmizerany) Life360

·         Sebastián Vera (sebastianvera)

·         Ben Cronin (bcronin) LightStep

·         Ben Sigelman (bensigelman) LightStep

·         Onwukike Ibe (oike) Uber

·         Alexander Sorokin (syrnick)

·         Yuri Shkuro (yurishkuro) Uber

·         Yuri Shkuro (yurishkuro) Uber

·         Ben Sigelman (bensigelman) LightStep

·         Brandon Gonzales (bg451)

·         Dan Kuebrich (dkuebric) AppNeta

·         Ben Sigelman (bensigelman) LightStep

·         Adrian Cole (adriancole) Pivotal / Zipkin

·         Mck (michaelsembwever) Apache / Cassandra

·         Onwukike Ibe (oike) Uber

·         Yuri Shkuro (yurishkuro) Uber

·         Mohamed Ezzat (m-ezzat)

·         Christian Weiss (cwe1ss) Consultant

·         Daniel Wallin (dawallin) Frontwalker

·         Ben Sigelman (bensigelman)

·         Ben Sigelman (bensigelman) LightStep

·         Josh MacDonald (jmacd) LightStep

·         Dimitrios Kouzis-Loukas (lookfwd) Bloomberg

·         Ben Sigelman (bensigelman) LightStep

 

 

--

Chris Aniszczyk (@cra) | +1-512-961-6719


_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



Re: [VOTE] OpenTracing Project Proposal

Kenneth Owens (kenowens) <kenowens@...>
 

Yes

 

Kenneth Owens
CTO Cloud Native Platforms
Cloud Platforms and Services Group
kenowens@...
Phone: +1 408 424 0872
Mobile: +1 314 591 5708


Cisco.com

   

 

Think before you print. Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

 

 

From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Chris Aniszczyk via cncf-toc
Sent: Monday, September 26, 2016 10:48 AM
To: cncf-toc@...
Subject: [cncf-toc] [VOTE] OpenTracing Project Proposal

 

The OpenTracing (http://opentracing.io/) team has iterated on their project proposal to a final one which is ready for voting by TOC members: https://github.com/cncf/toc/pull/15

 

So please vote! The proposal is also embedded below for your convenience:

OpenTracing Proposal

Name of project: OpenTracing

Description: A set of consistent, expressive, vendor-neutral APIs for distributed tracing and context propagation, seeslides for the content we presented to the CNCF TOC.

Sponsor / Advisor from TOC: Bryan Cantrill <bryan@...>

Unique Identifier: opentracing

License: Apache License v2.0

Source control repositories:

Initial Committers:

·         Ben Sigelman (@bensigelman)

·         Yuri Shkuro (@yurishkuro)

·         see the Contributors section for more information

Infrastructure requirements: CI and potentially CNCF Community Cluster access

Issue tracker: global - https://github.com/opentracing/opentracing.github.io/issues and per-platform issues are raised on the per-platform repository’s issues area

Mailing lists

Release methodology and mechanics: Various across platforms

Social media accounts: Twitter: @opentracing

Existing sponsorship: Nothing formal; LightStep occasionally spends small amounts of money (hosting events, etc) on behalf of OpenTracing tech talks and so forth.

External Dependencies

Really very little. The core OpenTracing libraries are facade APIs and thus only bring in dependencies that are needed to describe various function parameters and return values. In some cases there are test harnesses that bring in ubiquitous testing packages. OpenTracing is willing to go through and formally enumerate all of these dependencies, but suffice to say there’s nothing interesting to see and everything is permissively licensed.

Statement on alignment with CNCF mission:

OpenTracing is an open API standard for distributed tracing in applications and OSS packages. Developers with experience building microservices at scale understand the role and importance of distributed tracing: per-process logging and metric monitoring have their place, but neither can reconstruct the elaborate journeys that transactions take as they propagate across a distributed system. Distributed traces are these journeys.

So if distributed tracing is so valuable, why doesn’t everyone do it already? Because tracing instrumentation has been fragmented, syntactically inconsistent, and thus excessively expensive to deploy end-to-end across most cloud-native stacks.

Distributed tracing is challenging because the instrumentation must propagate the tracing context both within and between processes. Accomplishing this involves many distinct pieces in a (micro-)service stack. In particular, tracing context must be passed through:

·         Self-contained OSS services (e.g., NGINX, Cassandra, Redis, etc)

·         OSS packages linked into custom services (e.g., grpc, ORMs, etc)

·         Arbitrary application glue and business logic built around the above

And there’s the rub: It is not reasonable to ask all OSS services and all OSS packages and all application-specific code to use a single tracing vendor; yet, if they don’t share a mechanism for trace description and propagation, the causal chain is broken and the traces are truncated, often to the point of uselessness. We need a single, standard mechanism to describe the behavior of our systems. OpenTracing is that single, standard mechanism.

Regarding CNCF’s charter mission, OpenTracing is specifically concerned with making loosely-coupled [micro]services easier to manage. As such, it is strongly aligned with CNCF and its goal to “significantly increase the overall agility and maintainability of applications” by “[making] technology ubiquitous and easily available through reliable interfaces.” Indeed, OpenTracing and CNCF as a whole mutually benefit one another. (It should be noted that, as it is focused on standard instrumentation more than standard encoding formats, OpenTracing today is most relevant at the application layer; it has few specific opinions about — or strong dependencies on — the container layer or orchestration systems more generally, though service discovery and high-quality tracing are symbiotic.)

Other Contributors:

OpenTracing Semantics Repo (formally the opentracing.github.io docs repo)

·         Ben Sigelman (bensigelman) LightStep

·         Yuri Shkuro (yurishkuro) Uber

·         Dan Kuebrich (dkuebric) AppNeta

·         Ben Cronin (bcronin) LightStep

·         Priyanka Sharma (pritianka) LightStep

·         Dimitrios Kouzis-Loukas (lookfwd) Bloomberg

·         Mck (michaelsembwever) Apache

·         Ivan Fraixedes (ifraixedes)

Github issue/discussion participation:

·         Rodrigo Fonseca (rfonseca) Brown University

·         Colin Patrick McCabe (cmccabe) Cloudera

·         Cagatay Kavukcuoglu (tinkerware) Base60Labs

·         Benjamin Eberlei (beberlei) Qafoo

·         Władysław Bodzek (wladekb)

·         Bogdan Drutu (bogdandrutu) Google

·         Grayson Koonce (breerly) Uber

·         Marcin Grzejszczak (marcingrzejszczak) Zipkin

·         Fabian Lange (CodingFabian) Instana

·         Paul Caporn (drpacman) BBC

·         Ben Sigelman (bensigelman) LightStep

·         Tobias Schottdorf (tschottdorf) Cockroach Labs

·         Yuri Shkuro (yurishkuro) Uber

·         Brandon Gonzales (bg451) Student

·         Josh MacDonald (jmacd)

·         Bas van Beek (basvanbeek)

·         Stephen Gutekanst (slimsag) Sourcegraph

·         Richard Scothern (RichardScothern) Docker

·         Tamir Duberstein (tamird) Cockroach Labs

·         Kris Kowal (kriskowal) (I think Uber)

·         Aleksey (IncSW)

·         Kyle Conroy (kyleconroy) Stripe

·         Blake Mizerany (bmizerany) Life360

·         Sebastián Vera (sebastianvera)

·         Ben Cronin (bcronin) LightStep

·         Ben Sigelman (bensigelman) LightStep

·         Onwukike Ibe (oike) Uber

·         Alexander Sorokin (syrnick)

·         Yuri Shkuro (yurishkuro) Uber

·         Yuri Shkuro (yurishkuro) Uber

·         Ben Sigelman (bensigelman) LightStep

·         Brandon Gonzales (bg451)

·         Dan Kuebrich (dkuebric) AppNeta

·         Ben Sigelman (bensigelman) LightStep

·         Adrian Cole (adriancole) Pivotal / Zipkin

·         Mck (michaelsembwever) Apache / Cassandra

·         Onwukike Ibe (oike) Uber

·         Yuri Shkuro (yurishkuro) Uber

·         Mohamed Ezzat (m-ezzat)

·         Christian Weiss (cwe1ss) Consultant

·         Daniel Wallin (dawallin) Frontwalker

·         Ben Sigelman (bensigelman)

·         Ben Sigelman (bensigelman) LightStep

·         Josh MacDonald (jmacd) LightStep

·         Dimitrios Kouzis-Loukas (lookfwd) Bloomberg

·         Ben Sigelman (bensigelman) LightStep

 

 

--

Chris Aniszczyk (@cra) | +1-512-961-6719


Re: [VOTE] OpenTracing Project Proposal

Bryan Cantrill <bryan@...>
 

Yes!

         - Bryan


On Sep 26, 2016 8:48 AM, "Chris Aniszczyk via cncf-toc" <cncf-toc@...> wrote:
The OpenTracing (http://opentracing.io/) team has iterated on their project proposal to a final one which is ready for voting by TOC members: https://github.com/cncf/toc/pull/15

So please vote! The proposal is also embedded below for your convenience:

OpenTracing Proposal

Name of project: OpenTracing

Description: A set of consistent, expressive, vendor-neutral APIs for distributed tracing and context propagation, seeslides for the content we presented to the CNCF TOC.

Sponsor / Advisor from TOC: Bryan Cantrill <bryan@...>

Unique Identifier: opentracing

License: Apache License v2.0

Source control repositories:

Initial Committers:

  • Ben Sigelman (@bensigelman)

  • Yuri Shkuro (@yurishkuro)

  • see the Contributors section for more information

Infrastructure requirements: CI and potentially CNCF Community Cluster access

Issue tracker: global - https://github.com/opentracing/opentracing.github.io/issues and per-platform issues are raised on the per-platform repository’s issues area

Mailing lists

Release methodology and mechanics: Various across platforms

Social media accounts: Twitter: @opentracing

Existing sponsorship: Nothing formal; LightStep occasionally spends small amounts of money (hosting events, etc) on behalf of OpenTracing tech talks and so forth.

External Dependencies

Really very little. The core OpenTracing libraries are facade APIs and thus only bring in dependencies that are needed to describe various function parameters and return values. In some cases there are test harnesses that bring in ubiquitous testing packages. OpenTracing is willing to go through and formally enumerate all of these dependencies, but suffice to say there’s nothing interesting to see and everything is permissively licensed.

Statement on alignment with CNCF mission:

OpenTracing is an open API standard for distributed tracing in applications and OSS packages. Developers with experience building microservices at scale understand the role and importance of distributed tracing: per-process logging and metric monitoring have their place, but neither can reconstruct the elaborate journeys that transactions take as they propagate across a distributed system. Distributed traces are these journeys.

So if distributed tracing is so valuable, why doesn’t everyone do it already? Because tracing instrumentation has been fragmented, syntactically inconsistent, and thus excessively expensive to deploy end-to-end across most cloud-native stacks.

Distributed tracing is challenging because the instrumentation must propagate the tracing context both within and between processes. Accomplishing this involves many distinct pieces in a (micro-)service stack. In particular, tracing context must be passed through:

  • Self-contained OSS services (e.g., NGINX, Cassandra, Redis, etc)

  • OSS packages linked into custom services (e.g., grpc, ORMs, etc)

  • Arbitrary application glue and business logic built around the above

And there’s the rub: It is not reasonable to ask all OSS services and all OSS packages and all application-specific code to use a single tracing vendor; yet, if they don’t share a mechanism for trace description and propagation, the causal chain is broken and the traces are truncated, often to the point of uselessness. We need a single, standard mechanism to describe the behavior of our systems. OpenTracing is that single, standard mechanism.

Regarding CNCF’s charter mission, OpenTracing is specifically concerned with making loosely-coupled [micro]services easier to manage. As such, it is strongly aligned with CNCF and its goal to “significantly increase the overall agility and maintainability of applications” by “[making] technology ubiquitous and easily available through reliable interfaces.” Indeed, OpenTracing and CNCF as a whole mutually benefit one another. (It should be noted that, as it is focused on standard instrumentation more than standard encoding formats, OpenTracing today is most relevant at the application layer; it has few specific opinions about — or strong dependencies on — the container layer or orchestration systems more generally, though service discovery and high-quality tracing are symbiotic.)

Other Contributors:

OpenTracing Semantics Repo (formally the opentracing.github.io docs repo)

  • Ben Sigelman (bensigelman) LightStep

  • Yuri Shkuro (yurishkuro) Uber

  • Dan Kuebrich (dkuebric) AppNeta

  • Ben Cronin (bcronin) LightStep

  • Priyanka Sharma (pritianka) LightStep

  • Dimitrios Kouzis-Loukas (lookfwd) Bloomberg

  • Mck (michaelsembwever) Apache

  • Ivan Fraixedes (ifraixedes)

Github issue/discussion participation:

  • Rodrigo Fonseca (rfonseca) Brown University

  • Colin Patrick McCabe (cmccabe) Cloudera

  • Cagatay Kavukcuoglu (tinkerware) Base60Labs

  • Benjamin Eberlei (beberlei) Qafoo

  • Władysław Bodzek (wladekb)

  • Bogdan Drutu (bogdandrutu) Google

  • Grayson Koonce (breerly) Uber

  • Marcin Grzejszczak (marcingrzejszczak) Zipkin

  • Fabian Lange (CodingFabian) Instana

  • Paul Caporn (drpacman) BBC

  • Ben Sigelman (bensigelman) LightStep

  • Tobias Schottdorf (tschottdorf) Cockroach Labs

  • Yuri Shkuro (yurishkuro) Uber

  • Brandon Gonzales (bg451) Student

  • Josh MacDonald (jmacd)

  • Bas van Beek (basvanbeek)

  • Stephen Gutekanst (slimsag) Sourcegraph

  • Richard Scothern (RichardScothern) Docker

  • Tamir Duberstein (tamird) Cockroach Labs

  • Kris Kowal (kriskowal) (I think Uber)

  • Aleksey (IncSW)

  • Kyle Conroy (kyleconroy) Stripe

  • Blake Mizerany (bmizerany) Life360

  • Sebastián Vera (sebastianvera)

  • Ben Cronin (bcronin) LightStep

  • Ben Sigelman (bensigelman) LightStep

  • Onwukike Ibe (oike) Uber

  • Alexander Sorokin (syrnick)

  • Yuri Shkuro (yurishkuro) Uber

  • Yuri Shkuro (yurishkuro) Uber

  • Ben Sigelman (bensigelman) LightStep

  • Brandon Gonzales (bg451)

  • Dan Kuebrich (dkuebric) AppNeta

  • Ben Sigelman (bensigelman) LightStep

  • Adrian Cole (adriancole) Pivotal / Zipkin

  • Mck (michaelsembwever) Apache / Cassandra

  • Onwukike Ibe (oike) Uber

  • Yuri Shkuro (yurishkuro) Uber

  • Mohamed Ezzat (m-ezzat)

  • Christian Weiss (cwe1ss) Consultant

  • Daniel Wallin (dawallin) Frontwalker

  • Ben Sigelman (bensigelman)

  • Ben Sigelman (bensigelman) LightStep

  • Josh MacDonald (jmacd) LightStep

  • Dimitrios Kouzis-Loukas (lookfwd) Bloomberg

  • Ben Sigelman (bensigelman) LightStep



--
Chris Aniszczyk (@cra) | +1-512-961-6719

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


Re: [VOTE] OpenTracing Project Proposal

Camille Fournier
 

Yes


On Sep 26, 2016 11:48 AM, "Chris Aniszczyk via cncf-toc" <cncf-toc@...> wrote:
The OpenTracing (http://opentracing.io/) team has iterated on their project proposal to a final one which is ready for voting by TOC members: https://github.com/cncf/toc/pull/15

So please vote! The proposal is also embedded below for your convenience:

OpenTracing Proposal

Name of project: OpenTracing

Description: A set of consistent, expressive, vendor-neutral APIs for distributed tracing and context propagation, seeslides for the content we presented to the CNCF TOC.

Sponsor / Advisor from TOC: Bryan Cantrill <bryan@...>

Unique Identifier: opentracing

License: Apache License v2.0

Source control repositories:

Initial Committers:

  • Ben Sigelman (@bensigelman)

  • Yuri Shkuro (@yurishkuro)

  • see the Contributors section for more information

Infrastructure requirements: CI and potentially CNCF Community Cluster access

Issue tracker: global - https://github.com/opentracing/opentracing.github.io/issues and per-platform issues are raised on the per-platform repository’s issues area

Mailing lists

Release methodology and mechanics: Various across platforms

Social media accounts: Twitter: @opentracing

Existing sponsorship: Nothing formal; LightStep occasionally spends small amounts of money (hosting events, etc) on behalf of OpenTracing tech talks and so forth.

External Dependencies

Really very little. The core OpenTracing libraries are facade APIs and thus only bring in dependencies that are needed to describe various function parameters and return values. In some cases there are test harnesses that bring in ubiquitous testing packages. OpenTracing is willing to go through and formally enumerate all of these dependencies, but suffice to say there’s nothing interesting to see and everything is permissively licensed.

Statement on alignment with CNCF mission:

OpenTracing is an open API standard for distributed tracing in applications and OSS packages. Developers with experience building microservices at scale understand the role and importance of distributed tracing: per-process logging and metric monitoring have their place, but neither can reconstruct the elaborate journeys that transactions take as they propagate across a distributed system. Distributed traces are these journeys.

So if distributed tracing is so valuable, why doesn’t everyone do it already? Because tracing instrumentation has been fragmented, syntactically inconsistent, and thus excessively expensive to deploy end-to-end across most cloud-native stacks.

Distributed tracing is challenging because the instrumentation must propagate the tracing context both within and between processes. Accomplishing this involves many distinct pieces in a (micro-)service stack. In particular, tracing context must be passed through:

  • Self-contained OSS services (e.g., NGINX, Cassandra, Redis, etc)

  • OSS packages linked into custom services (e.g., grpc, ORMs, etc)

  • Arbitrary application glue and business logic built around the above

And there’s the rub: It is not reasonable to ask all OSS services and all OSS packages and all application-specific code to use a single tracing vendor; yet, if they don’t share a mechanism for trace description and propagation, the causal chain is broken and the traces are truncated, often to the point of uselessness. We need a single, standard mechanism to describe the behavior of our systems. OpenTracing is that single, standard mechanism.

Regarding CNCF’s charter mission, OpenTracing is specifically concerned with making loosely-coupled [micro]services easier to manage. As such, it is strongly aligned with CNCF and its goal to “significantly increase the overall agility and maintainability of applications” by “[making] technology ubiquitous and easily available through reliable interfaces.” Indeed, OpenTracing and CNCF as a whole mutually benefit one another. (It should be noted that, as it is focused on standard instrumentation more than standard encoding formats, OpenTracing today is most relevant at the application layer; it has few specific opinions about — or strong dependencies on — the container layer or orchestration systems more generally, though service discovery and high-quality tracing are symbiotic.)

Other Contributors:

OpenTracing Semantics Repo (formally the opentracing.github.io docs repo)

  • Ben Sigelman (bensigelman) LightStep

  • Yuri Shkuro (yurishkuro) Uber

  • Dan Kuebrich (dkuebric) AppNeta

  • Ben Cronin (bcronin) LightStep

  • Priyanka Sharma (pritianka) LightStep

  • Dimitrios Kouzis-Loukas (lookfwd) Bloomberg

  • Mck (michaelsembwever) Apache

  • Ivan Fraixedes (ifraixedes)

Github issue/discussion participation:

  • Rodrigo Fonseca (rfonseca) Brown University

  • Colin Patrick McCabe (cmccabe) Cloudera

  • Cagatay Kavukcuoglu (tinkerware) Base60Labs

  • Benjamin Eberlei (beberlei) Qafoo

  • Władysław Bodzek (wladekb)

  • Bogdan Drutu (bogdandrutu) Google

  • Grayson Koonce (breerly) Uber

  • Marcin Grzejszczak (marcingrzejszczak) Zipkin

  • Fabian Lange (CodingFabian) Instana

  • Paul Caporn (drpacman) BBC

  • Ben Sigelman (bensigelman) LightStep

  • Tobias Schottdorf (tschottdorf) Cockroach Labs

  • Yuri Shkuro (yurishkuro) Uber

  • Brandon Gonzales (bg451) Student

  • Josh MacDonald (jmacd)

  • Bas van Beek (basvanbeek)

  • Stephen Gutekanst (slimsag) Sourcegraph

  • Richard Scothern (RichardScothern) Docker

  • Tamir Duberstein (tamird) Cockroach Labs

  • Kris Kowal (kriskowal) (I think Uber)

  • Aleksey (IncSW)

  • Kyle Conroy (kyleconroy) Stripe

  • Blake Mizerany (bmizerany) Life360

  • Sebastián Vera (sebastianvera)

  • Ben Cronin (bcronin) LightStep

  • Ben Sigelman (bensigelman) LightStep

  • Onwukike Ibe (oike) Uber

  • Alexander Sorokin (syrnick)

  • Yuri Shkuro (yurishkuro) Uber

  • Yuri Shkuro (yurishkuro) Uber

  • Ben Sigelman (bensigelman) LightStep

  • Brandon Gonzales (bg451)

  • Dan Kuebrich (dkuebric) AppNeta

  • Ben Sigelman (bensigelman) LightStep

  • Adrian Cole (adriancole) Pivotal / Zipkin

  • Mck (michaelsembwever) Apache / Cassandra

  • Onwukike Ibe (oike) Uber

  • Yuri Shkuro (yurishkuro) Uber

  • Mohamed Ezzat (m-ezzat)

  • Christian Weiss (cwe1ss) Consultant

  • Daniel Wallin (dawallin) Frontwalker

  • Ben Sigelman (bensigelman)

  • Ben Sigelman (bensigelman) LightStep

  • Josh MacDonald (jmacd) LightStep

  • Dimitrios Kouzis-Loukas (lookfwd) Bloomberg

  • Ben Sigelman (bensigelman) LightStep



--
Chris Aniszczyk (@cra) | +1-512-961-6719

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


Re: [VOTE] OpenTracing Project Proposal

Benjamin Hindman
 

Yes (binding)

On Mon, Sep 26, 2016 at 8:48 AM, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:
The OpenTracing (http://opentracing.io/) team has iterated on their project proposal to a final one which is ready for voting by TOC members: https://github.com/cncf/toc/pull/15

So please vote! The proposal is also embedded below for your convenience:

OpenTracing Proposal

Name of project: OpenTracing

Description: A set of consistent, expressive, vendor-neutral APIs for distributed tracing and context propagation, seeslides for the content we presented to the CNCF TOC.

Sponsor / Advisor from TOC: Bryan Cantrill <bryan@...>

Unique Identifier: opentracing

License: Apache License v2.0

Source control repositories:

Initial Committers:

  • Ben Sigelman (@bensigelman)

  • Yuri Shkuro (@yurishkuro)

  • see the Contributors section for more information

Infrastructure requirements: CI and potentially CNCF Community Cluster access

Issue tracker: global - https://github.com/opentracing/opentracing.github.io/issues and per-platform issues are raised on the per-platform repository’s issues area

Mailing lists

Release methodology and mechanics: Various across platforms

Social media accounts: Twitter: @opentracing

Existing sponsorship: Nothing formal; LightStep occasionally spends small amounts of money (hosting events, etc) on behalf of OpenTracing tech talks and so forth.

External Dependencies

Really very little. The core OpenTracing libraries are facade APIs and thus only bring in dependencies that are needed to describe various function parameters and return values. In some cases there are test harnesses that bring in ubiquitous testing packages. OpenTracing is willing to go through and formally enumerate all of these dependencies, but suffice to say there’s nothing interesting to see and everything is permissively licensed.

Statement on alignment with CNCF mission:

OpenTracing is an open API standard for distributed tracing in applications and OSS packages. Developers with experience building microservices at scale understand the role and importance of distributed tracing: per-process logging and metric monitoring have their place, but neither can reconstruct the elaborate journeys that transactions take as they propagate across a distributed system. Distributed traces are these journeys.

So if distributed tracing is so valuable, why doesn’t everyone do it already? Because tracing instrumentation has been fragmented, syntactically inconsistent, and thus excessively expensive to deploy end-to-end across most cloud-native stacks.

Distributed tracing is challenging because the instrumentation must propagate the tracing context both within and between processes. Accomplishing this involves many distinct pieces in a (micro-)service stack. In particular, tracing context must be passed through:

  • Self-contained OSS services (e.g., NGINX, Cassandra, Redis, etc)

  • OSS packages linked into custom services (e.g., grpc, ORMs, etc)

  • Arbitrary application glue and business logic built around the above

And there’s the rub: It is not reasonable to ask all OSS services and all OSS packages and all application-specific code to use a single tracing vendor; yet, if they don’t share a mechanism for trace description and propagation, the causal chain is broken and the traces are truncated, often to the point of uselessness. We need a single, standard mechanism to describe the behavior of our systems. OpenTracing is that single, standard mechanism.

Regarding CNCF’s charter mission, OpenTracing is specifically concerned with making loosely-coupled [micro]services easier to manage. As such, it is strongly aligned with CNCF and its goal to “significantly increase the overall agility and maintainability of applications” by “[making] technology ubiquitous and easily available through reliable interfaces.” Indeed, OpenTracing and CNCF as a whole mutually benefit one another. (It should be noted that, as it is focused on standard instrumentation more than standard encoding formats, OpenTracing today is most relevant at the application layer; it has few specific opinions about — or strong dependencies on — the container layer or orchestration systems more generally, though service discovery and high-quality tracing are symbiotic.)

Other Contributors:

OpenTracing Semantics Repo (formally the opentracing.github.io docs repo)

  • Ben Sigelman (bensigelman) LightStep

  • Yuri Shkuro (yurishkuro) Uber

  • Dan Kuebrich (dkuebric) AppNeta

  • Ben Cronin (bcronin) LightStep

  • Priyanka Sharma (pritianka) LightStep

  • Dimitrios Kouzis-Loukas (lookfwd) Bloomberg

  • Mck (michaelsembwever) Apache

  • Ivan Fraixedes (ifraixedes)

Github issue/discussion participation:

  • Rodrigo Fonseca (rfonseca) Brown University

  • Colin Patrick McCabe (cmccabe) Cloudera

  • Cagatay Kavukcuoglu (tinkerware) Base60Labs

  • Benjamin Eberlei (beberlei) Qafoo

  • Władysław Bodzek (wladekb)

  • Bogdan Drutu (bogdandrutu) Google

  • Grayson Koonce (breerly) Uber

  • Marcin Grzejszczak (marcingrzejszczak) Zipkin

  • Fabian Lange (CodingFabian) Instana

  • Paul Caporn (drpacman) BBC

  • Ben Sigelman (bensigelman) LightStep

  • Tobias Schottdorf (tschottdorf) Cockroach Labs

  • Yuri Shkuro (yurishkuro) Uber

  • Brandon Gonzales (bg451) Student

  • Josh MacDonald (jmacd)

  • Bas van Beek (basvanbeek)

  • Stephen Gutekanst (slimsag) Sourcegraph

  • Richard Scothern (RichardScothern) Docker

  • Tamir Duberstein (tamird) Cockroach Labs

  • Kris Kowal (kriskowal) (I think Uber)

  • Aleksey (IncSW)

  • Kyle Conroy (kyleconroy) Stripe

  • Blake Mizerany (bmizerany) Life360

  • Sebastián Vera (sebastianvera)

  • Ben Cronin (bcronin) LightStep

  • Ben Sigelman (bensigelman) LightStep

  • Onwukike Ibe (oike) Uber

  • Alexander Sorokin (syrnick)

  • Yuri Shkuro (yurishkuro) Uber

  • Yuri Shkuro (yurishkuro) Uber

  • Ben Sigelman (bensigelman) LightStep

  • Brandon Gonzales (bg451)

  • Dan Kuebrich (dkuebric) AppNeta

  • Ben Sigelman (bensigelman) LightStep

  • Adrian Cole (adriancole) Pivotal / Zipkin

  • Mck (michaelsembwever) Apache / Cassandra

  • Onwukike Ibe (oike) Uber

  • Yuri Shkuro (yurishkuro) Uber

  • Mohamed Ezzat (m-ezzat)

  • Christian Weiss (cwe1ss) Consultant

  • Daniel Wallin (dawallin) Frontwalker

  • Ben Sigelman (bensigelman)

  • Ben Sigelman (bensigelman) LightStep

  • Josh MacDonald (jmacd) LightStep

  • Dimitrios Kouzis-Loukas (lookfwd) Bloomberg

  • Ben Sigelman (bensigelman) LightStep



--
Chris Aniszczyk (@cra) | +1-512-961-6719

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc




--
Benjamin Hindman
Founder of Mesosphere and Co-Creator of Apache Mesos

Follow us on Twitter: @mesosphere


Re: [VOTE] OpenTracing Project Proposal

Solomon Hykes
 

Yes.

On Mon, Sep 26, 2016 at 8:48 AM, Chris Aniszczyk via cncf-toc
<cncf-toc@lists.cncf.io> wrote:
The OpenTracing (http://opentracing.io/) team has iterated on their project
proposal to a final one which is ready for voting by TOC members:
https://github.com/cncf/toc/pull/15

So please vote! The proposal is also embedded below for your convenience:

OpenTracing Proposal

Name of project: OpenTracing

Description: A set of consistent, expressive, vendor-neutral APIs for
distributed tracing and context propagation, seeslides for the content we
presented to the CNCF TOC.

Sponsor / Advisor from TOC: Bryan Cantrill <bryan@joyent.com>

Unique Identifier: opentracing

License: Apache License v2.0

Source control repositories:

https://github.com/opentracing

https://github.com/opentracing-contrib

Initial Committers:

Ben Sigelman (@bensigelman)

Yuri Shkuro (@yurishkuro)

see the Contributors section for more information

Infrastructure requirements: CI and potentially CNCF Community Cluster
access

Issue tracker: global -
https://github.com/opentracing/opentracing.github.io/issues and per-platform
issues are raised on the per-platform repository’s issues area

Mailing lists

Active: https://gitter.im/opentracing/public

Placeholder: https://groups.google.com/forum/#!forum/opentracing

Related: https://groups.google.com/forum/#!forum/distributed-tracing

Website: http://opentracing.io

Release methodology and mechanics: Various across platforms

Social media accounts: Twitter: @opentracing

Existing sponsorship: Nothing formal; LightStep occasionally spends small
amounts of money (hosting events, etc) on behalf of OpenTracing tech talks
and so forth.

External Dependencies

Really very little. The core OpenTracing libraries are facade APIs and thus
only bring in dependencies that are needed to describe various function
parameters and return values. In some cases there are test harnesses that
bring in ubiquitous testing packages. OpenTracing is willing to go through
and formally enumerate all of these dependencies, but suffice to say there’s
nothing interesting to see and everything is permissively licensed.

Statement on alignment with CNCF mission:

OpenTracing is an open API standard for distributed tracing in applications
and OSS packages. Developers with experience building microservices at scale
understand the role and importance of distributed tracing: per-process
logging and metric monitoring have their place, but neither can reconstruct
the elaborate journeys that transactions take as they propagate across a
distributed system. Distributed traces are these journeys.

So if distributed tracing is so valuable, why doesn’t everyone do it
already? Because tracing instrumentation has been fragmented, syntactically
inconsistent, and thus excessively expensive to deploy end-to-end across
most cloud-native stacks.

Distributed tracing is challenging because the instrumentation must
propagate the tracing context both within and between processes.
Accomplishing this involves many distinct pieces in a (micro-)service stack.
In particular, tracing context must be passed through:

Self-contained OSS services (e.g., NGINX, Cassandra, Redis, etc)

OSS packages linked into custom services (e.g., grpc, ORMs, etc)

Arbitrary application glue and business logic built around the above

And there’s the rub: It is not reasonable to ask all OSS services and all
OSS packages and all application-specific code to use a single tracing
vendor; yet, if they don’t share a mechanism for trace description and
propagation, the causal chain is broken and the traces are truncated, often
to the point of uselessness. We need a single, standard mechanism to
describe the behavior of our systems. OpenTracing is that single, standard
mechanism.

Regarding CNCF’s charter mission, OpenTracing is specifically concerned with
making loosely-coupled [micro]services easier to manage. As such, it is
strongly aligned with CNCF and its goal to “significantly increase the
overall agility and maintainability of applications” by “[making] technology
ubiquitous and easily available through reliable interfaces.” Indeed,
OpenTracing and CNCF as a whole mutually benefit one another. (It should be
noted that, as it is focused on standard instrumentation more than standard
encoding formats, OpenTracing today is most relevant at the application
layer; it has few specific opinions about — or strong dependencies on — the
container layer or orchestration systems more generally, though service
discovery and high-quality tracing are symbiotic.)

See also: the OpenTracing raison d’être on Medium

Other Contributors:

OpenTracing Semantics Repo (formally the opentracing.github.io docs repo)

Ben Sigelman (bensigelman) LightStep

Yuri Shkuro (yurishkuro) Uber

Dan Kuebrich (dkuebric) AppNeta

Ben Cronin (bcronin) LightStep

Priyanka Sharma (pritianka) LightStep

Dimitrios Kouzis-Loukas (lookfwd) Bloomberg

Mck (michaelsembwever) Apache

Ivan Fraixedes (ifraixedes)

Github issue/discussion participation:

Rodrigo Fonseca (rfonseca) Brown University

Colin Patrick McCabe (cmccabe) Cloudera

Cagatay Kavukcuoglu (tinkerware) Base60Labs

Benjamin Eberlei (beberlei) Qafoo

Władysław Bodzek (wladekb)

Bogdan Drutu (bogdandrutu) Google

Grayson Koonce (breerly) Uber

Marcin Grzejszczak (marcingrzejszczak) Zipkin

Fabian Lange (CodingFabian) Instana

Paul Caporn (drpacman) BBC

https://github.com/opentracing/opentracing-go

Ben Sigelman (bensigelman) LightStep

Tobias Schottdorf (tschottdorf) Cockroach Labs

Yuri Shkuro (yurishkuro) Uber

Brandon Gonzales (bg451) Student

Josh MacDonald (jmacd)

Bas van Beek (basvanbeek)

Stephen Gutekanst (slimsag) Sourcegraph

Richard Scothern (RichardScothern) Docker

Tamir Duberstein (tamird) Cockroach Labs

Kris Kowal (kriskowal) (I think Uber)

Aleksey (IncSW)

Kyle Conroy (kyleconroy) Stripe

Blake Mizerany (bmizerany) Life360

Sebastián Vera (sebastianvera)

https://github.com/opentracing/opentracing-javascript

Ben Cronin (bcronin) LightStep

Ben Sigelman (bensigelman) LightStep

Onwukike Ibe (oike) Uber

Alexander Sorokin (syrnick)

Yuri Shkuro (yurishkuro) Uber

https://github.com/opentracing/opentracing-python

Yuri Shkuro (yurishkuro) Uber

Ben Sigelman (bensigelman) LightStep

Brandon Gonzales (bg451)

Dan Kuebrich (dkuebric) AppNeta

https://github.com/opentracing/opentracing-java

Ben Sigelman (bensigelman) LightStep

Adrian Cole (adriancole) Pivotal / Zipkin

Mck (michaelsembwever) Apache / Cassandra

Onwukike Ibe (oike) Uber

Yuri Shkuro (yurishkuro) Uber

Mohamed Ezzat (m-ezzat)

https://github.com/opentracing/opentracing-csharp

Christian Weiss (cwe1ss) Consultant

Daniel Wallin (dawallin) Frontwalker

Ben Sigelman (bensigelman)

https://github.com/opentracing/opentracing-objc

Ben Sigelman (bensigelman) LightStep

https://github.com/opentracing/opentracing-cpp

Josh MacDonald (jmacd) LightStep

Dimitrios Kouzis-Loukas (lookfwd) Bloomberg

Ben Sigelman (bensigelman) LightStep



--
Chris Aniszczyk (@cra) | +1-512-961-6719

_______________________________________________
cncf-toc mailing list
cncf-toc@lists.cncf.io
https://lists.cncf.io/mailman/listinfo/cncf-toc


Re: [VOTE] OpenTracing Project Proposal

Joseph Jacks <jjacks@...>
 

YES (non-binding)


Re: [VOTE] OpenTracing Project Proposal

Joseph Jacks <jjacks@...>
 

YES


Re: CNCF Governance Proposal

Alex Baretto
 

Thank you Dan

Sent from my iPhone

On Sep 26, 2016, at 9:17 AM, Dan Kohn <dan@...> wrote:

Thanks for the comments. I've incorporated changes based on your feedback to https://docs.google.com/document/d/1l6e-hW7C3S6xJjGn47hUKKxeFBxiamAK7kn5efSryxY/edit#

On Wed, Sep 21, 2016 7:57 PM, Alex Baretto via cncf-toc cncf-toc@... wrote:
Hello all,

I've been reviewing the recent Graduation Proposal on behalf of Huawei. I have recently joined the TOC meetings so I may have missed some of the earlier discussions.

I have the following questions:
- I wanted some clarity on the styling of the graduation evaluation criteria. OSS project possess their idiosyncrasies, and whilst the proposal puts forward good ideas to capture these, the terminology may not clarify them sufficiently, as under the present proposal. 
- It may be good to consider inclusion of more explicit language regarding 
  -- "multiple end users" - we may want to specify whether this is more then 2 users or more than 3 users, etc.

Changed to at least 2

  -- "committers from more than one organization..." - we may want to specify that this means having committers from more than two organizations

Changed.

  -- "no longer can be recommended" - do we have detailed criteria in mind for non-recommendation? ASF? 

No, this is left to the discretion of the TOC. But the implication is that the world has changed significantly since adopting the project. It should certainly not come as a surprise.

  -- "no longer represents best practices in its area" - similarly, do we have detailed criteria in mind?

This is left intentionally vague. Note that the project is not "shut down" in any practical sense. It's simply a statement that CNCF/the TOC can no longer recommend the project, or cannot do so except with certain caveats.


Thank you.

Alexandre Baretto

--
Dan Kohn <mailto:dan@...>
Executive Director, Cloud Native Computing Foundation <https://cncf.io/>
tel:+1-415-233-1000


Re: CNCF Governance Proposal

Dan Kohn <dan@...>
 

Thanks for the comments. I've incorporated changes based on your feedback to https://docs.google.com/document/d/1l6e-hW7C3S6xJjGn47hUKKxeFBxiamAK7kn5efSryxY/edit#

On Wed, Sep 21, 2016 7:57 PM, Alex Baretto via cncf-toc cncf-toc@... wrote:
Hello all,

I've been reviewing the recent Graduation Proposal on behalf of Huawei. I have recently joined the TOC meetings so I may have missed some of the earlier discussions.

I have the following questions:
- I wanted some clarity on the styling of the graduation evaluation criteria. OSS project possess their idiosyncrasies, and whilst the proposal puts forward good ideas to capture these, the terminology may not clarify them sufficiently, as under the present proposal. 
- It may be good to consider inclusion of more explicit language regarding 
  -- "multiple end users" - we may want to specify whether this is more then 2 users or more than 3 users, etc.

Changed to at least 2

  -- "committers from more than one organization..." - we may want to specify that this means having committers from more than two organizations

Changed.

  -- "no longer can be recommended" - do we have detailed criteria in mind for non-recommendation? ASF? 

No, this is left to the discretion of the TOC. But the implication is that the world has changed significantly since adopting the project. It should certainly not come as a surprise.

  -- "no longer represents best practices in its area" - similarly, do we have detailed criteria in mind?

This is left intentionally vague. Note that the project is not "shut down" in any practical sense. It's simply a statement that CNCF/the TOC can no longer recommend the project, or cannot do so except with certain caveats.


Thank you.

Alexandre Baretto

--
Dan Kohn <mailto:dan@...>
Executive Director, Cloud Native Computing Foundation <https://cncf.io/>
tel:+1-415-233-1000


Re: [VOTE] OpenTracing Project Proposal

alexis richardson
 

YES


On Mon, Sep 26, 2016 at 4:48 PM, Chris Aniszczyk via cncf-toc
<cncf-toc@lists.cncf.io> wrote:
The OpenTracing (http://opentracing.io/) team has iterated on their project
proposal to a final one which is ready for voting by TOC members:
https://github.com/cncf/toc/pull/15

So please vote! The proposal is also embedded below for your convenience:

OpenTracing Proposal

Name of project: OpenTracing

Description: A set of consistent, expressive, vendor-neutral APIs for
distributed tracing and context propagation, seeslides for the content we
presented to the CNCF TOC.

Sponsor / Advisor from TOC: Bryan Cantrill <bryan@joyent.com>

Unique Identifier: opentracing

License: Apache License v2.0

Source control repositories:

https://github.com/opentracing

https://github.com/opentracing-contrib

Initial Committers:

Ben Sigelman (@bensigelman)

Yuri Shkuro (@yurishkuro)

see the Contributors section for more information

Infrastructure requirements: CI and potentially CNCF Community Cluster
access

Issue tracker: global -
https://github.com/opentracing/opentracing.github.io/issues and per-platform
issues are raised on the per-platform repository’s issues area

Mailing lists

Active: https://gitter.im/opentracing/public

Placeholder: https://groups.google.com/forum/#!forum/opentracing

Related: https://groups.google.com/forum/#!forum/distributed-tracing

Website: http://opentracing.io

Release methodology and mechanics: Various across platforms

Social media accounts: Twitter: @opentracing

Existing sponsorship: Nothing formal; LightStep occasionally spends small
amounts of money (hosting events, etc) on behalf of OpenTracing tech talks
and so forth.

External Dependencies

Really very little. The core OpenTracing libraries are facade APIs and thus
only bring in dependencies that are needed to describe various function
parameters and return values. In some cases there are test harnesses that
bring in ubiquitous testing packages. OpenTracing is willing to go through
and formally enumerate all of these dependencies, but suffice to say there’s
nothing interesting to see and everything is permissively licensed.

Statement on alignment with CNCF mission:

OpenTracing is an open API standard for distributed tracing in applications
and OSS packages. Developers with experience building microservices at scale
understand the role and importance of distributed tracing: per-process
logging and metric monitoring have their place, but neither can reconstruct
the elaborate journeys that transactions take as they propagate across a
distributed system. Distributed traces are these journeys.

So if distributed tracing is so valuable, why doesn’t everyone do it
already? Because tracing instrumentation has been fragmented, syntactically
inconsistent, and thus excessively expensive to deploy end-to-end across
most cloud-native stacks.

Distributed tracing is challenging because the instrumentation must
propagate the tracing context both within and between processes.
Accomplishing this involves many distinct pieces in a (micro-)service stack.
In particular, tracing context must be passed through:

Self-contained OSS services (e.g., NGINX, Cassandra, Redis, etc)

OSS packages linked into custom services (e.g., grpc, ORMs, etc)

Arbitrary application glue and business logic built around the above

And there’s the rub: It is not reasonable to ask all OSS services and all
OSS packages and all application-specific code to use a single tracing
vendor; yet, if they don’t share a mechanism for trace description and
propagation, the causal chain is broken and the traces are truncated, often
to the point of uselessness. We need a single, standard mechanism to
describe the behavior of our systems. OpenTracing is that single, standard
mechanism.

Regarding CNCF’s charter mission, OpenTracing is specifically concerned with
making loosely-coupled [micro]services easier to manage. As such, it is
strongly aligned with CNCF and its goal to “significantly increase the
overall agility and maintainability of applications” by “[making] technology
ubiquitous and easily available through reliable interfaces.” Indeed,
OpenTracing and CNCF as a whole mutually benefit one another. (It should be
noted that, as it is focused on standard instrumentation more than standard
encoding formats, OpenTracing today is most relevant at the application
layer; it has few specific opinions about — or strong dependencies on — the
container layer or orchestration systems more generally, though service
discovery and high-quality tracing are symbiotic.)

See also: the OpenTracing raison d’être on Medium

Other Contributors:

OpenTracing Semantics Repo (formally the opentracing.github.io docs repo)

Ben Sigelman (bensigelman) LightStep

Yuri Shkuro (yurishkuro) Uber

Dan Kuebrich (dkuebric) AppNeta

Ben Cronin (bcronin) LightStep

Priyanka Sharma (pritianka) LightStep

Dimitrios Kouzis-Loukas (lookfwd) Bloomberg

Mck (michaelsembwever) Apache

Ivan Fraixedes (ifraixedes)

Github issue/discussion participation:

Rodrigo Fonseca (rfonseca) Brown University

Colin Patrick McCabe (cmccabe) Cloudera

Cagatay Kavukcuoglu (tinkerware) Base60Labs

Benjamin Eberlei (beberlei) Qafoo

Władysław Bodzek (wladekb)

Bogdan Drutu (bogdandrutu) Google

Grayson Koonce (breerly) Uber

Marcin Grzejszczak (marcingrzejszczak) Zipkin

Fabian Lange (CodingFabian) Instana

Paul Caporn (drpacman) BBC

https://github.com/opentracing/opentracing-go

Ben Sigelman (bensigelman) LightStep

Tobias Schottdorf (tschottdorf) Cockroach Labs

Yuri Shkuro (yurishkuro) Uber

Brandon Gonzales (bg451) Student

Josh MacDonald (jmacd)

Bas van Beek (basvanbeek)

Stephen Gutekanst (slimsag) Sourcegraph

Richard Scothern (RichardScothern) Docker

Tamir Duberstein (tamird) Cockroach Labs

Kris Kowal (kriskowal) (I think Uber)

Aleksey (IncSW)

Kyle Conroy (kyleconroy) Stripe

Blake Mizerany (bmizerany) Life360

Sebastián Vera (sebastianvera)

https://github.com/opentracing/opentracing-javascript

Ben Cronin (bcronin) LightStep

Ben Sigelman (bensigelman) LightStep

Onwukike Ibe (oike) Uber

Alexander Sorokin (syrnick)

Yuri Shkuro (yurishkuro) Uber

https://github.com/opentracing/opentracing-python

Yuri Shkuro (yurishkuro) Uber

Ben Sigelman (bensigelman) LightStep

Brandon Gonzales (bg451)

Dan Kuebrich (dkuebric) AppNeta

https://github.com/opentracing/opentracing-java

Ben Sigelman (bensigelman) LightStep

Adrian Cole (adriancole) Pivotal / Zipkin

Mck (michaelsembwever) Apache / Cassandra

Onwukike Ibe (oike) Uber

Yuri Shkuro (yurishkuro) Uber

Mohamed Ezzat (m-ezzat)

https://github.com/opentracing/opentracing-csharp

Christian Weiss (cwe1ss) Consultant

Daniel Wallin (dawallin) Frontwalker

Ben Sigelman (bensigelman)

https://github.com/opentracing/opentracing-objc

Ben Sigelman (bensigelman) LightStep

https://github.com/opentracing/opentracing-cpp

Josh MacDonald (jmacd) LightStep

Dimitrios Kouzis-Loukas (lookfwd) Bloomberg

Ben Sigelman (bensigelman) LightStep



--
Chris Aniszczyk (@cra) | +1-512-961-6719

_______________________________________________
cncf-toc mailing list
cncf-toc@lists.cncf.io
https://lists.cncf.io/mailman/listinfo/cncf-toc


[VOTE] OpenTracing Project Proposal

Chris Aniszczyk
 

The OpenTracing (http://opentracing.io/) team has iterated on their project proposal to a final one which is ready for voting by TOC members: https://github.com/cncf/toc/pull/15

So please vote! The proposal is also embedded below for your convenience:

OpenTracing Proposal

Name of project: OpenTracing

Description: A set of consistent, expressive, vendor-neutral APIs for distributed tracing and context propagation, seeslides for the content we presented to the CNCF TOC.

Sponsor / Advisor from TOC: Bryan Cantrill <bryan@...>

Unique Identifier: opentracing

License: Apache License v2.0

Source control repositories:

Initial Committers:

  • Ben Sigelman (@bensigelman)

  • Yuri Shkuro (@yurishkuro)

  • see the Contributors section for more information

Infrastructure requirements: CI and potentially CNCF Community Cluster access

Issue tracker: global - https://github.com/opentracing/opentracing.github.io/issues and per-platform issues are raised on the per-platform repository’s issues area

Mailing lists

Release methodology and mechanics: Various across platforms

Social media accounts: Twitter: @opentracing

Existing sponsorship: Nothing formal; LightStep occasionally spends small amounts of money (hosting events, etc) on behalf of OpenTracing tech talks and so forth.

External Dependencies

Really very little. The core OpenTracing libraries are facade APIs and thus only bring in dependencies that are needed to describe various function parameters and return values. In some cases there are test harnesses that bring in ubiquitous testing packages. OpenTracing is willing to go through and formally enumerate all of these dependencies, but suffice to say there’s nothing interesting to see and everything is permissively licensed.

Statement on alignment with CNCF mission:

OpenTracing is an open API standard for distributed tracing in applications and OSS packages. Developers with experience building microservices at scale understand the role and importance of distributed tracing: per-process logging and metric monitoring have their place, but neither can reconstruct the elaborate journeys that transactions take as they propagate across a distributed system. Distributed traces are these journeys.

So if distributed tracing is so valuable, why doesn’t everyone do it already? Because tracing instrumentation has been fragmented, syntactically inconsistent, and thus excessively expensive to deploy end-to-end across most cloud-native stacks.

Distributed tracing is challenging because the instrumentation must propagate the tracing context both within and between processes. Accomplishing this involves many distinct pieces in a (micro-)service stack. In particular, tracing context must be passed through:

  • Self-contained OSS services (e.g., NGINX, Cassandra, Redis, etc)

  • OSS packages linked into custom services (e.g., grpc, ORMs, etc)

  • Arbitrary application glue and business logic built around the above

And there’s the rub: It is not reasonable to ask all OSS services and all OSS packages and all application-specific code to use a single tracing vendor; yet, if they don’t share a mechanism for trace description and propagation, the causal chain is broken and the traces are truncated, often to the point of uselessness. We need a single, standard mechanism to describe the behavior of our systems. OpenTracing is that single, standard mechanism.

Regarding CNCF’s charter mission, OpenTracing is specifically concerned with making loosely-coupled [micro]services easier to manage. As such, it is strongly aligned with CNCF and its goal to “significantly increase the overall agility and maintainability of applications” by “[making] technology ubiquitous and easily available through reliable interfaces.” Indeed, OpenTracing and CNCF as a whole mutually benefit one another. (It should be noted that, as it is focused on standard instrumentation more than standard encoding formats, OpenTracing today is most relevant at the application layer; it has few specific opinions about — or strong dependencies on — the container layer or orchestration systems more generally, though service discovery and high-quality tracing are symbiotic.)

Other Contributors:

OpenTracing Semantics Repo (formally the opentracing.github.io docs repo)

  • Ben Sigelman (bensigelman) LightStep

  • Yuri Shkuro (yurishkuro) Uber

  • Dan Kuebrich (dkuebric) AppNeta

  • Ben Cronin (bcronin) LightStep

  • Priyanka Sharma (pritianka) LightStep

  • Dimitrios Kouzis-Loukas (lookfwd) Bloomberg

  • Mck (michaelsembwever) Apache

  • Ivan Fraixedes (ifraixedes)

Github issue/discussion participation:

  • Rodrigo Fonseca (rfonseca) Brown University

  • Colin Patrick McCabe (cmccabe) Cloudera

  • Cagatay Kavukcuoglu (tinkerware) Base60Labs

  • Benjamin Eberlei (beberlei) Qafoo

  • Władysław Bodzek (wladekb)

  • Bogdan Drutu (bogdandrutu) Google

  • Grayson Koonce (breerly) Uber

  • Marcin Grzejszczak (marcingrzejszczak) Zipkin

  • Fabian Lange (CodingFabian) Instana

  • Paul Caporn (drpacman) BBC

  • Ben Sigelman (bensigelman) LightStep

  • Tobias Schottdorf (tschottdorf) Cockroach Labs

  • Yuri Shkuro (yurishkuro) Uber

  • Brandon Gonzales (bg451) Student

  • Josh MacDonald (jmacd)

  • Bas van Beek (basvanbeek)

  • Stephen Gutekanst (slimsag) Sourcegraph

  • Richard Scothern (RichardScothern) Docker

  • Tamir Duberstein (tamird) Cockroach Labs

  • Kris Kowal (kriskowal) (I think Uber)

  • Aleksey (IncSW)

  • Kyle Conroy (kyleconroy) Stripe

  • Blake Mizerany (bmizerany) Life360

  • Sebastián Vera (sebastianvera)

  • Ben Cronin (bcronin) LightStep

  • Ben Sigelman (bensigelman) LightStep

  • Onwukike Ibe (oike) Uber

  • Alexander Sorokin (syrnick)

  • Yuri Shkuro (yurishkuro) Uber

  • Yuri Shkuro (yurishkuro) Uber

  • Ben Sigelman (bensigelman) LightStep

  • Brandon Gonzales (bg451)

  • Dan Kuebrich (dkuebric) AppNeta

  • Ben Sigelman (bensigelman) LightStep

  • Adrian Cole (adriancole) Pivotal / Zipkin

  • Mck (michaelsembwever) Apache / Cassandra

  • Onwukike Ibe (oike) Uber

  • Yuri Shkuro (yurishkuro) Uber

  • Mohamed Ezzat (m-ezzat)

  • Christian Weiss (cwe1ss) Consultant

  • Daniel Wallin (dawallin) Frontwalker

  • Ben Sigelman (bensigelman)

  • Ben Sigelman (bensigelman) LightStep

  • Josh MacDonald (jmacd) LightStep

  • Dimitrios Kouzis-Loukas (lookfwd) Bloomberg

  • Ben Sigelman (bensigelman) LightStep



--
Chris Aniszczyk (@cra) | +1-512-961-6719


Reminder: RFC on OpenTracing Project Proposal

Chris Aniszczyk
 

The OpenTracing.io project proposal is up for review: 
https://github.com/cncf/toc/pull/15

If there are no major issues I will call for a formal project vote on Monday morning the 26th!

Have a great weekend!

--
Chris Aniszczyk (@cra) | +1-512-961-6719


Re: CNCF Governance Proposal

Alex Baretto
 

Thanks, I will incorporate these therein.


On Sep 21, 2016 8:55 PM, "Alexis Richardson" <alexis@...> wrote:
Alex

All discussion on this matter was in the doc, so you didn't miss
anything.  Please DO feel free to suggest edits in the doc.  That
would be great.

alexis

On Thu, Sep 22, 2016 at 12:57 AM, Alex Baretto via cncf-toc
<cncf-toc@...> wrote:
> Hello all,
>
> I've been reviewing the recent Graduation Proposal on behalf of Huawei. I
> have recently joined the TOC meetings so I may have missed some of the
> earlier discussions.
>
> I have the following questions:
> - I wanted some clarity on the styling of the graduation evaluation
> criteria. OSS project possess their idiosyncrasies, and whilst the proposal
> puts forward good ideas to capture these, the terminology may not clarify
> them sufficiently, as under the present proposal.
> - It may be good to consider inclusion of more explicit language regarding
>   -- "multiple end users" - we may want to specify whether this is more then
> 2 users or more than 3 users, etc.
>   -- "committers from more than one organization..." - we may want to
> specify that this means having committers from more than two organizations
>   -- "no longer can be recommended" - do we have detailed criteria in mind
> for non-recommendation? ASF?
>   -- "no longer represents best practices in its area" - similarly, do we
> have detailed criteria in mind?
>
> Thank you.
>
> Alexandre Baretto
> axbaretto@...
>
> _______________________________________________
> cncf-toc mailing list
> cncf-toc@...
> https://lists.cncf.io/mailman/listinfo/cncf-toc
>


Re: CNCF Governance Proposal

alexis richardson
 

Alex

All discussion on this matter was in the doc, so you didn't miss
anything. Please DO feel free to suggest edits in the doc. That
would be great.

alexis

On Thu, Sep 22, 2016 at 12:57 AM, Alex Baretto via cncf-toc
<cncf-toc@lists.cncf.io> wrote:
Hello all,

I've been reviewing the recent Graduation Proposal on behalf of Huawei. I
have recently joined the TOC meetings so I may have missed some of the
earlier discussions.

I have the following questions:
- I wanted some clarity on the styling of the graduation evaluation
criteria. OSS project possess their idiosyncrasies, and whilst the proposal
puts forward good ideas to capture these, the terminology may not clarify
them sufficiently, as under the present proposal.
- It may be good to consider inclusion of more explicit language regarding
-- "multiple end users" - we may want to specify whether this is more then
2 users or more than 3 users, etc.
-- "committers from more than one organization..." - we may want to
specify that this means having committers from more than two organizations
-- "no longer can be recommended" - do we have detailed criteria in mind
for non-recommendation? ASF?
-- "no longer represents best practices in its area" - similarly, do we
have detailed criteria in mind?

Thank you.

Alexandre Baretto
axbaretto@gmail.com

_______________________________________________
cncf-toc mailing list
cncf-toc@lists.cncf.io
https://lists.cncf.io/mailman/listinfo/cncf-toc


CNCF Governance Proposal

Alex Baretto
 

Hello all,

I've been reviewing the recent Graduation Proposal on behalf of Huawei. I have recently joined the TOC meetings so I may have missed some of the earlier discussions.

I have the following questions:
- I wanted some clarity on the styling of the graduation evaluation criteria. OSS project possess their idiosyncrasies, and whilst the proposal puts forward good ideas to capture these, the terminology may not clarify them sufficiently, as under the present proposal. 
- It may be good to consider inclusion of more explicit language regarding 
  -- "multiple end users" - we may want to specify whether this is more then 2 users or more than 3 users, etc.
  -- "committers from more than one organization..." - we may want to specify that this means having committers from more than two organizations
  -- "no longer can be recommended" - do we have detailed criteria in mind for non-recommendation? ASF? 
  -- "no longer represents best practices in its area" - similarly, do we have detailed criteria in mind?

Thank you.

Alexandre Baretto


Re: Kubernetes Code of Conduct

alexis richardson
 

thanks both


TOC people, please consider the Kubernetes CoC for CNCF, and others
linked in the GH issue




On Wed, Sep 21, 2016 at 4:51 PM, Chris Aniszczyk via cncf-toc
<cncf-toc@lists.cncf.io> wrote:
Here's the relevant GitHub issue:
https://github.com/cncf/foundation/issues/2

On Wed, Sep 21, 2016 at 10:50 AM, Sarah Novotny via cncf-toc
<cncf-toc@lists.cncf.io> wrote:


Here's our Code of Conduct.


https://github.com/kubernetes/kubernetes/blob/648ec14390afd3b3220191c038a379f6a1cc7cf8/code-of-conduct.md

_______________________________________________
cncf-toc mailing list
cncf-toc@lists.cncf.io
https://lists.cncf.io/mailman/listinfo/cncf-toc


--
Chris Aniszczyk (@cra) | +1-512-961-6719

_______________________________________________
cncf-toc mailing list
cncf-toc@lists.cncf.io
https://lists.cncf.io/mailman/listinfo/cncf-toc


Re: Kubernetes Code of Conduct

Chris Aniszczyk
 

Here's the relevant GitHub issue: https://github.com/cncf/foundation/issues/2

On Wed, Sep 21, 2016 at 10:50 AM, Sarah Novotny via cncf-toc <cncf-toc@...> wrote:

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc




--
Chris Aniszczyk (@cra) | +1-512-961-6719


Kubernetes Code of Conduct

Sarah Novotny <sarahnovotny@...>
 


RFC: OpenTracing Project Proposal for CNCF

Chris Aniszczyk
 

The OpenTracing (http://opentracing.io/) project proposal is ready for review here:

The proposal is being sponsored by Bryan Cantrill from the CNCF TOC.

Please make any comments on the proposal and if there are no major issues, I will formally kick off a vote for accepting the project into the CNCF on Monday.

Thanks!

--
Chris Aniszczyk (@cra) | +1-512-961-6719

6141 - 6160 of 6526