3 p.m.
Hi,
This is about the following RFEs:
https://issues.redhat.com/browse/WFLY-19835
https://issues.redhat.com/browse/WFLY-19836
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.
https://github.com/wildfly/wildfly/blob/main/microprofile/reactive-messag...
This config source has the max ordinal
<https://github.com/wildfly/wildfly/blob/main/microprofile/reactive-messag...;,
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 Tracer
2) Adjust the properties to allow for tracing to happen
I 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?
Thanks,
Kabir