Closed mx-psi closed 2 months ago
@mx-psi Are all those even valid use cases to have something in the Host?
E.g. the ballast extension example does not depend on Host implementing anything, it just looks for a specific extension + interface, which is a pattern that I think is more useful (e.g. Jaeger components often interact this way by requiring a specific extension to exist and then using that extension's specific APIs).
The zpages example looks like a hack that was not well-designed. It seems that it's adding an endpoint handler to some central server (admin server?). If so, it seems it could also be solved with an extension dependency, e.g. we could have an admin server extension that other components could add endpoints too (e.g. healthcheck extension could add HC endpoint).
It seems that it's adding an endpoint handler to some central server (admin server?). If so, it seems it could also be solved with an extension dependency, e.g. we could have an admin server extension that other components could add endpoints too (e.g. healthcheck extension could add HC endpoint).
The way we would do this right now is to add the method to component.Host
.
I guess the question here is: is it required for the service to implement this zpages support? Or do we consider it optional?
guess the question here is: is it required for the service to implement this zpages support? Or do we consider it optional?
Optional. I don't think every component.Host
implementation needs to be compatible with zpagesextension
. Conversely, I do think it is ok for a component.Host
to chose to be compatible with zpagesextenstion
.
If I understand zpages correctly, the zpagesextension handles creating the server, but it depends on the component.Host
to provide the data being served up. This is because the component.Host
is the thing managing all the pipelines, and it knows all the data zpagesextension
wants to serve up. If feels ok to me for a component.Host
implementation to simply not supply the information. This could because they have a different way of providing the same data and don't want to make it exposable via an extension.
Whatever the reason, it feels reasonable for zpagesextension
to check if the component.Host
implements the interfaces it requires. This pattern feels reasonable for any component that needs something extra from the component.Host
that isn't generally used by all components.
We have also used this strategy the other way around in the ballast extension:
I don't care for the pattern in this direction. When the component.Host
implementation (in our case service
), uses the pattern I feel like we're leaking component dependency into our component.Host
implementation. In my opinion it is ok for a component to ask the component.Host
for something but it is not ok for the component.Host
to ask a component for something.
Luckily the ballast extension is deprecated, so that use case will be removed soon.
Whatever the reason, it feels reasonable for zpagesextension to check if the component.Host implements the interfaces it requires. This pattern feels reasonable for any component that needs something extra from the component.Host that isn't generally used by all components.
This seems acceptable to me. We can require said components to specify the interface they need as part of their public API
For some components we cast the
component.Host
passed by the service to an interface that implementsRegisterZPages
hidden method which we check for here: https://github.com/open-telemetry/opentelemetry-collector/blob/91f13c309d00eef5b997a2e810effb2a4ccd95d4/extension/zpagesextension/zpagesextension.go#L58-L669511 discusses doing this for the receivercreator
We have also used this strategy the other way around in the ballast extension: https://github.com/open-telemetry/opentelemetry-collector/blob/91f13c309d00eef5b997a2e810effb2a4ccd95d4/service/service.go#L296-L300
In the context of service 1.0, I want to answer the following questions:
VERSIONING.md
)