On Wed, Oct 9, 2024 at 3:01 PM Kabir Khan <kkhan@redhat.com> wrote:Hi,This is about the following RFEs:They are about integrating the AMQP and Kafka connectors used by Reactive Messaging with OpenTelemetry tracing. I'd just like to brainstorm a bit before jumping in.The code is already there in SmallRye but is totally disabled in WildFly via this ConfigSource setting the mp.messaging.connector.smallrye-amqp.tracing-enabled and mp.messaging.connector.smallrye-kafka.tracing-enabled MP Config properties to false.This config source has the max ordinal, so it cannot be overridden at the moment.I think to enable this I need to:1) Add optional module dependencies from the connector modules to the Otel module providing Tracer2) Adjust the properties to allow for tracing to happenI think it makes sense to keep the default behaviour as not enabling tracing for backwards compatibility?To be able to enable tracing via MP Config, we would need to lower the ordinal of the config source providing these properties. This way deployments will be able to opt in to using tracing.However, if tracing is enabled and the OTel modules are not present, the SmallRye connectors will fail.So it seems I need to add an attribute to the currently empty subsystem to allow for tracing, and then do some capability/Galleon wiring to provision OTel if it indicates that we allow tracing. The value of the attribute would then influence the value of the ConfigSource properties behind the scenes.Since OTel being present is a yes/no situation, we could get away with one attribute - but perhaps it makes sense to allow configuration for this for each connector separately. Not sure how that works with the provisioning, but I guess if both of these depend on OTel, and one of them is set to indicate Otel is needed, we're good.As for the values of the attributes, I am thinking:* never - this sets the properties in the config source as it does at present, where it is set to false with a max ordinal so deployments can not override it* off - this would set the config source properties to false again, but with an ordinal value that can be overridden in the deployment (and system properties, env vars etc). So it is off by default but can be turned on* on - this would set the config source properties to true, but with an ordinal value that can be overridden in the deployment (and system properties, env vars etc). So it is on by default but can be turned off* always - this is like 'never' so the config source ordinal is the maximum, and the properties are set to true. Thus deployments can not opt out.Does the capability stuff work so that if the value of the subsystem attributes are off, on or always I add the requirement? And I don't if it is never?Any other thoughts/suggestions/objections?Galleon can't make provisioning decisions based on attribute values, other than understanding the dynamic part of capability references a la a socket binding name. The management API in general can't express that kind of "require capability X is value is Y" thing. Which is why Galleon can't figure out the requirements and provision accordingly.
I think you need a resource, with your 'never' concept not being an attribute value but rather the absence of the resource. AIUI the other options all allow for the possibility of turning it on and thus require provisioning of the required stuff. The resource expresses the capability requirement._______________________________________________Thanks,Kabir
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@lists.jboss.org
Privacy Statement: https://www.redhat.com/en/about/privacy-policy
List Archives: https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message/UPDGDJRMONYM2VWW6BGUVILKXETIXOW4/
--Brian StansberryPrincipal Architect, Red Hat JBoss EAPWildFly Project LeadHe/Him/His