+1, nb
From:
cncf-toc@... <cncf-toc@...> on behalf of Amye Scavarda Perrin via lists.cncf.io <ascavarda=linuxfoundation.org@...>
Date: Tuesday, 6. July 2021 at 21:33
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] [VOTE] OpenTelemetry for incubation
This email may contain confidential information. If it appears this message was sent to you by mistake, please let us know of the error. In this case, we also ask that you do not further forward the content and delete it. Thank you for your cooperation and
understanding. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4020 Linz, Austria, Am Fünfundzwanziger Turm 20.
|
|
toggle quoted message
Show quoted text
On Tue, Jul 6, 2021 at 8:28 PM Amye Scavarda Perrin < ascavarda@...> wrote:
|
|
|
|
Sheng Liang <sheng.liang@...>
toggle quoted message
Show quoted text
From: cncf-toc@... <cncf-toc@...>
On Behalf Of Hausenblas, Michael via lists.cncf.io
Sent: Wednesday, July 7, 2021 5:24 AM
To: cncf-toc@...
Subject: Re: [cncf-toc] [VOTE] OpenTelemetry for incubation
+1 non-binding
|
|
Eduardo,
Thank you for advocating on behalf of end-users.
Keeping focus on end-user adoption, experience, and ensuring that components maturity is communicated to the users transparently ( http://opentelemetry.io/status/ ), was an essential part of OpenTelemetry Due Diligence. OpenTelemetry is widely adopted by end-user companies at scale, and interviewing them as part of the process was insightful. One of the common requests was to clarify OpenTracing place. OpenTracing is CNCF Incubating project, but it's being merged to OpenTelemtry which exists at Sandbox level. As a part of OpenTelemetry incubation, OpenTracing will be archived from CNCF; here is the deprecation plan: https://docs.google.com/document/d/1WgSQ7ZvzO-JHeZi_ECRC7dwIbJYHPoYSXJqS1hLDJgI/edit# . Another common question was around integration with OpenMetrics, and it is already being prioritized by OpenTelemetry team. Together with the Prometheus and OpenMetrics community, the workgroup was formed, with weekly meetings that move this work forward.
It is true that not all the signals are not GA at this point. And it's common for projects to have experimental features. Given OpenTelemetry scope, getting the remaining current features to GA will take some community effort. OpenTelemetry already has an inclusive governing model and diverse committers base. Project moving to Incubation will help with the community growth, existing features hardening and new features/integrations development.
-alena
toggle quoted message
Show quoted text
On Jul 6, 2021, at 3:23 PM, Eduardo Silva < eduardo@...> wrote:
-1 non-binding Disclaimer: I like OTel project and even in Fluent ecosystem we are working towards integration with it. My reasons might be controversial but I think OTel is not ready for incubation "yet". As an end-user and project maintainer, I care about usability. OTel aims to cover Traces, Metrics, and Logs: At this point, only Traces are in GA state. Usable. Metrics: API and SDKs are "DRAFT" and the collector is experimental. Per my understanding, there is no stable integration with openmetrics or Prometheus ecosystem (for me and "many companies" this is a must). Partial usable. Logs: API and SDKs are "DRAFT", the collector is experimental. Not usable.
A project at the incubation stage has to demonstrate maturity and wide adoption, if this is not the case as a foundation (CNCF) we might be sending the wrong message to the end users. We aim to incubate projects with enough maturity and a minimal level of usability, but this is not the case. This is nothing against OTel but a purely technical opinion. I know we cannot incubate a sub-set of it like Traces only, but this is a complete offering and there are missing pieces of integration and implementation. I think moving OTel to incubation might help cloud vendors to spread the message, but what about the end users? The formal doc states: "TOC acknowledged the gaps in stability and adoption of significant Logging and Metric parts of the OpenTelemetry project. TOC confirmed it should not be a blocker for incubation. " I disagree, I think this is a blocker, there is so much pressure from vendors..., and rushing things might not be beneficial for the long term. Why not wait a bit more and do a proper incubation with the minimal pieces on it? I think staying in Sandbox a bit more will be beneficial for the project while rushing it might hurt the ecosystem.
On Tue, Jul 6, 2021 at 3:31 PM Amye Scavarda Perrin < ascavarda@...> wrote:
--
|
|
Hi Alena,
My primary concerns are Metrics and Logs, I was asked by a couple of techs leads about my opinion and I am pretty much sharing the same.
For an incubation project, maturity and adoption are required, I know that first hand by our experience with the Fluentd project. As you mention some areas are being prioritized to fill the gaps, which is great, but now when doing a "checkpoint evaluation" I simply think is not yet ready, the question is: is it ready for incubation now, or will be ready later ?.
Definitely moving a project from Sandbox -> Incubation helps in many areas such as marketing and adoption, but we don't aim to be a blocker on that, adoption must be organic.
As a bit of context, at Fluentd we are integrating metrics too as part of our processing and forwarding pipeline, and our evaluation ended up with: we have to integrate with Prometheus ecosystem first (open metrics) because Opentelemetry is not yet ready. So how can we tell the end-users that this project is incubating by solving A, B, C but only A is ready? I know this is a complex topic. If Otel moves to incubation today, for us (Fluentd) the maturity and specs will be the same, we will take the same decision to wait for some more maturity, so it's not ready.
I am not against Opentelemetry, all the opposite, I want Opentelemetry to succeed (we will natively integrate with it!) and I think providing more time to mature Metrics and Logs is highly beneficial, but rushing it to increase adoption and vendors awareness is not.
I am pretty sure Opentelemetry might get the votes to move forward anyway, but this is my technical opinion based on experience as a maintainer and being around on CNCF for some time.
Simply, there is nothing wrong to be in Sandbox a bit more time to get more maturity...
best,
toggle quoted message
Show quoted text
Eduardo,
Thank you for advocating on behalf of end-users.
Keeping focus on end-user adoption, experience, and ensuring that components maturity is communicated to the users transparently ( http://opentelemetry.io/status/ ), was an essential part of OpenTelemetry Due Diligence. OpenTelemetry is widely adopted by end-user companies at scale, and interviewing them as part of the process was insightful. One of the common requests was to clarify OpenTracing place. OpenTracing is CNCF Incubating project, but it's being merged to OpenTelemtry which exists at Sandbox level. As a part of OpenTelemetry incubation, OpenTracing will be archived from CNCF; here is the deprecation plan: https://docs.google.com/document/d/1WgSQ7ZvzO-JHeZi_ECRC7dwIbJYHPoYSXJqS1hLDJgI/edit# . Another common question was around integration with OpenMetrics, and it is already being prioritized by OpenTelemetry team. Together with the Prometheus and OpenMetrics community, the workgroup was formed, with weekly meetings that move this work forward.
It is true that not all the signals are not GA at this point. And it's common for projects to have experimental features. Given OpenTelemetry scope, getting the remaining current features to GA will take some community effort. OpenTelemetry already has an inclusive governing model and diverse committers base. Project moving to Incubation will help with the community growth, existing features hardening and new features/integrations development.
-alena On Jul 6, 2021, at 3:23 PM, Eduardo Silva < eduardo@...> wrote:
-1 non-binding Disclaimer: I like OTel project and even in Fluent ecosystem we are working towards integration with it. My reasons might be controversial but I think OTel is not ready for incubation "yet". As an end-user and project maintainer, I care about usability. OTel aims to cover Traces, Metrics, and Logs: At this point, only Traces are in GA state. Usable. Metrics: API and SDKs are "DRAFT" and the collector is experimental. Per my understanding, there is no stable integration with openmetrics or Prometheus ecosystem (for me and "many companies" this is a must). Partial usable. Logs: API and SDKs are "DRAFT", the collector is experimental. Not usable.
A project at the incubation stage has to demonstrate maturity and wide adoption, if this is not the case as a foundation (CNCF) we might be sending the wrong message to the end users. We aim to incubate projects with enough maturity and a minimal level of usability, but this is not the case. This is nothing against OTel but a purely technical opinion. I know we cannot incubate a sub-set of it like Traces only, but this is a complete offering and there are missing pieces of integration and implementation. I think moving OTel to incubation might help cloud vendors to spread the message, but what about the end users? The formal doc states: "TOC acknowledged the gaps in stability and adoption of significant Logging and Metric parts of the OpenTelemetry project. TOC confirmed it should not be a blocker for incubation. " I disagree, I think this is a blocker, there is so much pressure from vendors..., and rushing things might not be beneficial for the long term. Why not wait a bit more and do a proper incubation with the minimal pieces on it? I think staying in Sandbox a bit more will be beneficial for the project while rushing it might hurt the ecosystem.
On Tue, Jul 6, 2021 at 3:31 PM Amye Scavarda Perrin < ascavarda@...> wrote:
--
|
|
Perhaps as a counterpoint, I am aware of several hundred customers using OpenTelemetry in production. With OTEL tracing already heavily used and metrics expected to hit GA by the end of the year I personally feel thatOpentelemetry is what we would expect of an incubating project to be. My $0.02, Mark
Sent from my mobile phone
toggle quoted message
Show quoted text
On Jul 7, 2021, at 11:21 AM, Eduardo Silva <eduardo@...> wrote: Hi Alena,
My primary concerns are Metrics and Logs, I was asked by a couple of techs leads about my opinion and I am pretty much sharing the same.
For an incubation project, maturity and adoption are required, I know that first hand by our experience with the Fluentd project. As you mention some areas are being prioritized to fill the gaps, which is great, but now when doing a "checkpoint evaluation" I simply think is not yet ready, the question is: is it ready for incubation now, or will be ready later ?.
Definitely moving a project from Sandbox -> Incubation helps in many areas such as marketing and adoption, but we don't aim to be a blocker on that, adoption must be organic.
As a bit of context, at Fluentd we are integrating metrics too as part of our processing and forwarding pipeline, and our evaluation ended up with: we have to integrate with Prometheus ecosystem first (open metrics) because Opentelemetry is not yet ready. So how can we tell the end-users that this project is incubating by solving A, B, C but only A is ready? I know this is a complex topic. If Otel moves to incubation today, for us (Fluentd) the maturity and specs will be the same, we will take the same decision to wait for some more maturity, so it's not ready.
I am not against Opentelemetry, all the opposite, I want Opentelemetry to succeed (we will natively integrate with it!) and I think providing more time to mature Metrics and Logs is highly beneficial, but rushing it to increase adoption and vendors awareness is not.
I am pretty sure Opentelemetry might get the votes to move forward anyway, but this is my technical opinion based on experience as a maintainer and being around on CNCF for some time.
Simply, there is nothing wrong to be in Sandbox a bit more time to get more maturity...
best,
Eduardo,
Thank you for advocating on behalf of end-users.
Keeping focus on end-user adoption, experience, and ensuring that components maturity is communicated to the users transparently ( http://opentelemetry.io/status/ ), was an essential part of OpenTelemetry Due Diligence. OpenTelemetry is widely adopted by end-user companies at scale, and interviewing them as part of the process was insightful. One of the common requests was to clarify OpenTracing place. OpenTracing is CNCF Incubating project, but it's being merged to OpenTelemtry which exists at Sandbox level. As a part of OpenTelemetry incubation, OpenTracing will be archived from CNCF; here is the deprecation plan: https://docs.google.com/document/d/1WgSQ7ZvzO-JHeZi_ECRC7dwIbJYHPoYSXJqS1hLDJgI/edit# . Another common question was around integration with OpenMetrics, and it is already being prioritized by OpenTelemetry team. Together with the Prometheus and OpenMetrics community, the workgroup was formed, with weekly meetings that move this work forward.
It is true that not all the signals are not GA at this point. And it's common for projects to have experimental features. Given OpenTelemetry scope, getting the remaining current features to GA will take some community effort. OpenTelemetry already has an inclusive governing model and diverse committers base. Project moving to Incubation will help with the community growth, existing features hardening and new features/integrations development.
-alena On Jul 6, 2021, at 3:23 PM, Eduardo Silva < eduardo@...> wrote:
-1 non-binding Disclaimer: I like OTel project and even in Fluent ecosystem we are working towards integration with it. My reasons might be controversial but I think OTel is not ready for incubation "yet". As an end-user and project maintainer, I care about usability. OTel aims to cover Traces, Metrics, and Logs: At this point, only Traces are in GA state. Usable. Metrics: API and SDKs are "DRAFT" and the collector is experimental. Per my understanding, there is no stable integration with openmetrics or Prometheus ecosystem (for me and "many companies" this is a must). Partial usable. Logs: API and SDKs are "DRAFT", the collector is experimental. Not usable.
A project at the incubation stage has to demonstrate maturity and wide adoption, if this is not the case as a foundation (CNCF) we might be sending the wrong message to the end users. We aim to incubate projects with enough maturity and a minimal level of usability, but this is not the case. This is nothing against OTel but a purely technical opinion. I know we cannot incubate a sub-set of it like Traces only, but this is a complete offering and there are missing pieces of integration and implementation. I think moving OTel to incubation might help cloud vendors to spread the message, but what about the end users? The formal doc states: "TOC acknowledged the gaps in stability and adoption of significant Logging and Metric parts of the OpenTelemetry project. TOC confirmed it should not be a blocker for incubation. " I disagree, I think this is a blocker, there is so much pressure from vendors..., and rushing things might not be beneficial for the long term. Why not wait a bit more and do a proper incubation with the minimal pieces on it? I think staying in Sandbox a bit more will be beneficial for the project while rushing it might hurt the ecosystem.
On Tue, Jul 6, 2021 at 3:31 PM Amye Scavarda Perrin < ascavarda@...> wrote:
--
--
|
|

Dennis Kieselhorst
|
|

Dave Zolotusky
toggle quoted message
Show quoted text
On Thu, Jul 8, 2021 at 7:06 AM Dennis Kieselhorst < deki@...> wrote: +1 non-binding
|
|
+1 binding
Best Regards,
Venkat | +91 9148984211
Desk | +91 80 410 57045
Lack Of Planning On Your Part,
Does not Constitute An Emergency On Mine.
toggle quoted message
Show quoted text
From: cncf-toc@... <cncf-toc@...>
On Behalf Of Dave Zolotusky via lists.cncf.io
Sent: Thursday, July 8, 2021 11:48 AM
To: Dennis Kieselhorst <deki@...>
Cc: CNCF TOC <cncf-toc@...>
Subject: Re: [cncf-toc] [VOTE] OpenTelemetry for incubation
[**EXTERNAL EMAIL**]
On Thu, Jul 8, 2021 at 7:06 AM Dennis Kieselhorst <deki@...> wrote:
+1 non-binding
--
|
|