Stavros Kontopoulos

@ustiugov if you are referring to the OTEL client go lib afaik it is not ready from a metrics perspective. Tracing is in better shape upstream. Integrating with the OTEL...

@ustiugov cloudevents client is observability aware so if you try setup tracing as in https://knative.dev/docs/eventing/accessing-traces/ you should see them for existing components. Same applies to user services that utilize the...

Hi guys! Probably a gossip protocol would be more scalable eg. https://www.serf.io/docs/internals/gossip.html.

Yes let's start with the first option. The second one probably requires cloud vendors participation. How should we proceed with this?

@marcuslonnberg is this still true? There is no support for multi-stage builds? Would that be a lot of effort? This is a very useful feature nowadays.

Hi @eddie4941 if not mistaken other frameworks follow [this](https://github.com/kubernetes-sigs/controller-runtime/blob/4a8536eab22599e3af3c2cce2104e730b9c4ea65/pkg/webhook/admission/webhook.go#L142) during validation of any resource. I suspect that for example in a production env these errors should be minimal, you know...

@evankanderson I still see this issue here: https://github.com/knative/pkg/pull/2005#issuecomment-776174080

I have done an evaluation on this topic [here](https://docs.google.com/document/d/1_2RRAed7wHzU1NvPpR47AIRFu9TFZ_sp49Ge1h3v7lo/edit?usp=sharing) are the takeaways. From my POV otel is not ready yet, I would wait for GA. There is also a [spike](https://github.com/knative/eventing/issues/4769)...

@dprotaso I am fine with this as long as there is an option to define the component name etc. Right now for metrics like `source_name_event_count` ambiguity/conflict will be created when...

/hold