Re: [VOTE] OpenTelemetry for incubation


Eduardo Silva
 

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, 


On Wed, 7 Jul 2021 at 11:25, Alena Prokharchyk <aprokharchyk@...> wrote:
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, 6 Jul 2021 at 15:48, Bob Killen <killen.bob@...> wrote:
+1 non-binding.
\o/


On Tue, Jul 6, 2021 at 3:31 PM Amye Scavarda Perrin <ascavarda@...> wrote:
OpenTelemetry has applied to move from Sandbox to Incubation.

PR: https://github.com/cncf/toc/pull/619
Due Diligence (DD) doc: https://docs.google.com/document/d/1f4WQR6K84giyOCKjCsqcoVA8YUIzBhWZDVo3CwM1wuk/edit 

Alena Prokharchyk has called for public comment (https://lists.cncf.io/g/cncf-toc/message/5914) and has approved a call for a public vote.
  
Please vote (+1/0/-1) by replying to this thread.

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

-- 
Amye Scavarda Perrin | Program Manager | amye@...






-- 



Join cncf-toc@lists.cncf.io to automatically receive all group messages.