Hi Gabriele, +1 on the contribution repo. Regarding opentelemetry version, one of the first things I did when reading the proposal was to verify that the dependency version depends on quarkus version. Rule engine should use that one. For me the key thing is that OpenTelemetry is attached to a particular engine. The task essentially consists of implementing a listener and using the OpenTelemetry API to "describe" what the engine is doing. So, the implementation depends on internal engine details, it cannot be a Kogito global thing, but a per engine one (of course the dependency version used should be the same across the whole kogito ecosystem)
On Thu, Mar 5, 2026 at 4:47 PM Gabriele Cardosi <[email protected]> wrote: > Hi Francisco, > thanks for your question! > To be honest, I personally have not any strong opinion on that > OpenTelemetry feature itself. > The only thing I would like to double check (as soon as I can) is how it > interact with the OpenTelemetry usage inside sonataflow (e.g. are the same > versions ?) and how it can fit in the global schema, i.e.: could it be used > inside kogito applications ? If not, how to make it available there ? And, > in case, what would be the consequence of having such a feature available > in both quarkus and springboot environments ? > I hope this makes sense. > > > > I took the chance of this proposal to (try to) finally address the > underlying issue we have in general terms for this kind of situation (IMO). > I perfectly agree that, eventually, we should define a clear "promotion" > process. > > Side-note: if, ever, we agree on that experimental repo, I would be glad to > adapt the GH scripts. > > Best! > > Gabriele > > On Thu, Mar 5, 2026 at 12:22 PM Francisco Javier Tirado Sarti < > [email protected]> wrote: > > > Hi Gabriele, > > Just my 2 cents, because Im not a Drools contributor, and my opinion > should > > not prevent any decision that you guys consider proper. > > In general I agree that having another repository for "experimental" > stuff > > is a good idea. My doubt is whether "open-telemetry" should be > experimental > > or a "regular" add-on to the engine. Perhaps a process for "promotion" > > should be defined. And as a part of that process, a specific add-on can > be > > promoted directly to the "main" repository. > > I have to admit Im "biased" on favour of open-telemetry, which is > becoming > > a very useful tool for audit purposes (till the point that, for many > users, > > might become a replacement to data-index) > > > > On Thu, Mar 5, 2026 at 9:28 AM Gabriele Cardosi < > > [email protected]> > > wrote: > > > > > Hi Toshiya, > > > my idea would be that > > > 1. the "drools-experimental" repo would be built as the other > > "downstream" > > > repos > > > 2. PRs on "main" should not be considered "broken" if only the > > > drools-experimental repo fails to build (maybe just a warning ?) > > > 3. merging PRs in such "drools-experimental" should be very "easy" - > just > > > check that there is not bad or malicious code, and then let the > > > community "decide" if the feature is used/useful or not (*) > > > 4. until the experimental feature is in the drools-experimental repo, > the > > > proposer of such feature should also be responsible for maintaining it > > (*) > > > 5. artifacts built from the drools-experimental should be released to > > maven > > > repo to be publicly available, maybe with some conventional name to > > > indicate they are experimental (and, as such, absolutely no guarantee > in > > > any long term support) > > > > > > (*) > > > I'm aware that behind those very simple statements there could be a lot > > of > > > nuances and disagreement. > > > > > > > > > //// > > > To recap, what I'm driving at is: > > > 1. simplify and encourage contributors to propose features we may not > > even > > > think about > > > 2. avoid our own "bias" to influence the publication of such new > features > > > 3. enforce a sense of "belonging" to the community from the proposers, > > > making them responsible of what they propose until the feature finally > is > > > promoted to main > > > 4. avoid to increase the burden of maintenance of code that, in the > short > > > to long term, may prove to be unused or "dead" > > > > > > I hope to have answered your questions and that all of that makes > sense. > > > > > > Cheers > > > > > > Gabriele > > > > > > > > > > > > On Thu, Mar 5, 2026 at 8:44 AM Toshiya Kobayashi < > > > [email protected]> > > > wrote: > > > > > > > Hi Gabriele, > > > > > > > > Assuming "drools-experimental" repo is created, I think your point is > > > > its maintenance policy and CD/CI policy. Could you share your > thoughts > > > > on this? (e.g., Should the artifacts be released to maven repo? > Should > > > > "drools-experimental" repo CI be executed as downstream CI of > "drools" > > > > PR?) > > > > > > > > Thanks! > > > > Toshiya > > > > > > > > On Wed, Mar 4, 2026 at 5:23 PM Gabriele Cardosi > > > > <[email protected]> wrote: > > > > > > > > > > Alex, TOshiya, from my POV the idea of "experimental folder" > > introduce > > > a > > > > > logical and practical inconsistence, with downfall issues: > > > > > 1. from logical POV, it would mean that there would be "stable" > > (mean - > > > > > production ready) modules and code mixed with "unstable" (mean > > > > > experimental) code experimental > > > > > 2. there would be no way to avoid the latter impacting the former, > > > > whatever > > > > > problem may arise (dependency clashes, CVE, bugs) > > > > > 3. at ci level, the only way to differentiate a "stable" build with > > the > > > > > experimental one would be to create/duplicate CI scripts so that, > > e.g. > > > > > there would be a PR build that excludes the experimental module and > > > > another > > > > > one that include them (or, some similar "hack") that, again, would > be > > > > much > > > > > more cumbersome to maintain > > > > > > > > > > There is no "easy" solution, IMO, but the constant look for "easy > > > > solution" > > > > > always leads to "workarounds" that, soon after being implemented, > > > proved > > > > to > > > > > be problematic to maintain. > > > > > Complex problems require complex solutions to be properly addressed > > > and, > > > > > sorry, but the idea of an "experimental folder" mixed in the very > > same > > > > > "production-ready" code seems very naive to me. > > > > > > > > > > Cheers > > > > > > > > > > Gabriele > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Mar 4, 2026 at 3:13 AM Alex Porcelli <[email protected]> > > > > wrote: > > > > > > > > > > > The problem of your suggestion Gabriele is the CI complexity it > > > > introduces, > > > > > > being experimental or whatever.. I'd argue once accepted it > should > > be > > > > > > released.. and this also require being part of release > automation. > > > > > > > > > > > > We are already struggling with current complexity in place - see > > the > > > > email > > > > > > I sent early today about 10.2.0 release that I'm sure Kennedy is > > > > fighting > > > > > > hard. > > > > > > > > > > > > +1 for the experimental folder, I think Toshyia provided a very > > good > > > > > > initial framework we can start with.. and probably in a point in > > time > > > > we > > > > > > may want to refine it. > > > > > > > > > > > > Subhanshu, in the meantime while we discuss these topics in > > > parallel, I > > > > > > submitted a PR review… so please continue refining it.. don't get > > > this > > > > > > helpful and healthy discussion distract you from your > contribution. > > > > Thank > > > > > > you again! > > > > > > > > > > > > - > > > > > > Alex > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Mar 02, 2026 at 3:32 AM, Gabriele Cardosi < > > > > > > [email protected]> wrote: > > > > > > > > > > > > > Hi all, > > > > > > > one of the critical aspects with introducing new features, IMO, > > it > > > > is to > > > > > > > avoid that "main" branches ends up containing unused code (we > > > already > > > > > > have > > > > > > > a certain amount of that) that, anyway, we have to maintain, in > > > > terms of > > > > > > > security, library compatibility, etc.; basically, it will also > > > > impact the > > > > > > > CI build, with all consequent issues (see: clashing libraries > > > > versions, > > > > > > > framework upgrade hassle, etc). > > > > > > > Creating a specific directory inside the main branch does not > > solve > > > > any > > > > > > of > > > > > > > such problems (the name of a directory is just a human > > convention). > > > > In > > > > > > the > > > > > > > past I also remember the usage of "experimental" flags but, > > again, > > > > this > > > > > > > won't solve the above. > > > > > > > So, I would like to propose two different approaches, to both > > > > simplify > > > > > > the > > > > > > > introduction of new features from any contributor, on one side, > > and > > > > keep > > > > > > > integrity of our build, on the other side: > > > > > > > 1. a specific branch > > > > > > > 2. a specific repo > > > > > > > > > > > > > > I've not a strong opinion about any of the two. Anyway, with > > either > > > > of > > > > > > > those in place, maybe we would already have, in community, some > > > code > > > > > > that, > > > > > > > in the past, has been pushed back due to lack of clear > > > understanding > > > > and > > > > > > > other uncertainty. > > > > > > > And, again with that in place, that Opentelemetry feature would > > be > > > > easily > > > > > > > included in our domain. > > > > > > > (side-note: this is exactly the approach that has been followed > > by > > > > me, in > > > > > > > the past, after internal discussion with the so-called "drools" > > > > team). > > > > > > > > > > > > > > M2C > > > > > > > > > > > > > > Cheers > > > > > > > > > > > > > > On Mon, Mar 2, 2026 at 8:24 AM Toshiya Kobayashi > > > > <toshiyakobayashi@gmail. > > > > > > > com> wrote: > > > > > > > > > > > > > > Also, having a `contrib/experimental` area can help reduce > > > > maintenance > > > > > > > costs. For example, it could include disclaimers such as: > > > > > > > > > > > > > > - Experimental APIs may change in future releases. > > > > > > > - Experimental features may be removed in future releases. > > > > > > > - Experimental features must not block a release. For example, > if > > > an > > > > > > issue > > > > > > > is found in an experimental feature during the release process, > > we > > > > may > > > > > > > choose to disable that feature for the current release. > > > > > > > > > > > > > > This is just a proposal. I’d be happy to hear your thoughts. > > > > > > > > > > > > > > Toshiya > > > > > > > > > > > > > > On Fri, Feb 27, 2026 at 11:20 AM Toshiya Kobayashi > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > Thank you for moving this topic forward, Alex. > > > > > > > > > > > > > > I agree that criteria are required. > > > > > > > > > > > > > > What do you think would be reasonable criteria to establish? > > > > > > > > > > > > > > Here is a quick draft. Opinions are welcome: > > > > > > > > > > > > > > (Creation) > > > > > > > - A new feature module should default to contrib/experimental > > (not > > > > > > limited > > > > > > > to new contributors). > > > > > > > - If a developer wants to place the module elsewhere from the > > > > beginning, > > > > > > > they should start a thread on the dev mailing list (dev ML). If > > > > there are > > > > > > > no objections, it is accepted. If there are objections, a vote > > will > > > > be > > > > > > held > > > > > > > (Simple Majority vote: > > https://www.apache.org/foundation/glossary. > > > > > > > html#SimpleMajority). > > > > > > > > > > > > > > (Promotion) > > > > > > > - If anyone wants to promote the module to a different > location, > > > they > > > > > > > should start a thread on the dev ML. If there are no > objections, > > it > > > > is > > > > > > > accepted. If there are objections, a vote will be held (Simple > > > > Majority > > > > > > > vote). > > > > > > > > > > > > > > * These criteria do not apply to the creation of modules that > are > > > > not new > > > > > > > features (e.g., refactoring modules). > > > > > > > > > > > > > > Regards, > > > > > > > Toshiya > > > > > > > > > > > > > > On Fri, Feb 27, 2026 at 2:18 AM Alex Porcelli < > [email protected]> > > > > wrote: > > > > > > > > > > > > > > Subhanshu, > > > > > > > > > > > > > > Thank you for the contribution, it's great idea. I'll take some > > > time > > > > to > > > > > > > review soon. > > > > > > > > > > > > > > Now I'm sorry to hijack the thread…. > > > > > > > > > > > > > > Toshiya-san, > > > > > > > > > > > > > > The idea to have contrib/experimental makes total sense, but it > > > > misses > > > > > > > criteria. Lots of features have been added by new contributors > > > > without > > > > > > > > > > > > > > such > > > > > > > > > > > > > > experimental or contrib labels. > > > > > > > > > > > > > > I'm absolutely in favor of exploring this idea, but we need to > > > > define a > > > > > > > fair criteria for when a thing is flagged as > contrib/experimental > > > and > > > > > > > what's the criteria to promote it out of that status. > > > > > > > > > > > > > > Otherwise we risk creating inconsistency in how we treat > > > > contributions, > > > > > > > especially since we've accepted feature additions at the top > > level > > > in > > > > > > > > > > > > > > the > > > > > > > > > > > > > > recent past. > > > > > > > > > > > > > > What do you think would be reasonable criteria to establish? > > > > > > > > > > > > > > - > > > > > > > Alex > > > > > > > > > > > > > > On Wed, Feb 25, 2026 at 11:15 PM, Toshiya Kobayashi < > > > > toshiyakobayashi@ > > > > > > > gmail.com> wrote: > > > > > > > > > > > > > > Hi Subhanshu, > > > > > > > > > > > > > > Thank you for the contribution! > > > > > > > > > > > > > > The module looks good and will add value to the use cases you > > > > > > > > > > > > > > mentioned. > > > > > > > > > > > > > > My concern is that `drools-opentelemetry` looks like a feature > > > built > > > > > > > > > > > > > > on > > > > > > > > > > > > > > top of the Drools engine, so it may not be appropriate to place > > it > > > > > > > > > > > > > > at the > > > > > > > > > > > > > > top level of the `drools` repository. Maybe we could have an > > > umbrella > > > > > > > directory like `drools-contrib` or `drools-experimental`. Does > > > > > > > > > > > > > > anyone have > > > > > > > > > > > > > > thoughts? > > > > > > > > > > > > > > Toshiya > > > > > > > > > > > > > > On Wed, Feb 25, 2026 at 8:42 PM Francisco Javier Tirado Sarti > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > Hi, > > > > > > > Nice addition. > > > > > > > Although not completely related, I think it is worth mentioning > > > that > > > > > > > > > > > > > > there > > > > > > > > > > > > > > is already some OpenTelemetry usage in the kogito-runtimes > > > > > > > > > > > > > > repository. Here > > > > > > > > > > > > > > < > > > https://github.com/apache/incubator-kie-kogito-runtimes/tree/main/ > > > > > > > quarkus/addons/opentelemetry> node > > > > > > > listeners are used to trace the progress of the Workflow. I do > > not > > > > > > > > > > > > > > think > > > > > > > > > > > > > > it will conflict with what you are planning to do (If I > > understood > > > > > > > correctly, you are adding OpenTelemetry only to the rule > engine) > > > > > > > > > > > > > > Also, > > > > > > > > > > > > > > since Quarkus's POM handles OpenTelemetry dependencies, we are > > good > > > > > > > > > > > > > > on that > > > > > > > > > > > > > > too. > > > > > > > > > > > > > > On Wed, Feb 25, 2026 at 12:37 AM Subhanshu Bansal < > > > > > > > > > > > > > > subhanshu.bansal5566@ > > > > > > > > > > > > > > gmail.com> wrote: > > > > > > > > > > > > > > Hi Everyone, > > > > > > > > > > > > > > I have opened a PR to implement support for OpenTelemetry for > > > Drools. > > > > > > > > > > > > > > PR: https://github.com/apache/incubator-kie-drools/pull/6595 > > > > > > > > > > > > > > This is a separate module and why I used Open Telemetry > > > specifically > > > > > > > > > > > > > > is > > > > > > > > > > > > > > because it gives you production visibility into how your Drools > > > > > > > > > > > > > > rules are > > > > > > > > > > > > > > actually behaving in a running system. Here’s what that means > > > > > > > > > > > > > > concretely > > > > > > > > > > > > > > for this project:Distributed TracingWhen rules execute inside a > > > > > > > microservice, the TracingAgendaEventListener creates spans that > > > > > > > > > > > > > > connect to > > > > > > > > > > > > > > your existing traces. If a REST request hits your service, > > triggers > > > > > > > > > > > > > > rule > > > > > > > > > > > > > > evaluation, and then calls a downstream service, you get one > > > unified > > > > > > > > > > > > > > trace > > > > > > > > > > > > > > showing exactly which rules fired, how long each took, and what > > > > > > > > > > > > > > facts were > > > > > > > > > > > > > > involved. Without this, Drools is a black box inside your > trace — > > > > > > > > > > > > > > you see > > > > > > > > > > > > > > the request enter and leave, but nothing about the decision > logic > > > in > > > > > > > between.Metrics for Production MonitoringThe > > > > > > > > > > > > > > MetricsAgendaEventListener > > > > > > > > > > > > > > exposes counters and histograms that flow into whatever backend > > you > > > > > > > > > > > > > > already > > > > > > > > > > > > > > use (Prometheus, Datadog, Grafana, etc.). This lets you: > > > > > > > > > > > > > > - Alert when a rule suddenly fires 10x more than usual > (possible > > > data > > > > > > > issue or regression) > > > > > > > - Dashboard rule firing latency to catch performance > degradations > > > > > > > > > > > > > > before > > > > > > > > > > > > > > users notice > > > > > > > - Compare rule firing patterns across deployments (did the new > > rule > > > > > > > version change behavior?) > > > > > > > > > > > > > > Why OpenTelemetry specifically (vs. the existing Micrometer in > > > > > > > drools-metric)The existing drools-metric module focuses on > > internal > > > > > > > node-level constraint evaluation metrics via Micrometer. > > > > > > > > > > > > > > OpenTelemetry adds > > > > > > > > > > > > > > a different dimension with metrics and tracing. > > > > > > > > > > > > > > The key differentiator is correlation. When a customer > complaint > > > > > > > > > > > > > > comes in, > > > > > > > > > > > > > > an SRE can search traces by the request ID, see exactly which > > rules > > > > > > > > > > > > > > fired > > > > > > > > > > > > > > during that request, how long each took, and what facts were > > > > > > > > > > > > > > inserted — all > > > > > > > > > > > > > > without adding any logging or redeploying. That’s the > operational > > > > > > > > > > > > > > benefit > > > > > > > > > > > > > > that the existing drools-metric module doesn’t address. > > > > > > > > > > > > > > I am open to all the suggestions. Feel free to reach out. > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To > > > > > > > > > > > > > > unsubscribe, e-mail: [email protected] For > > additional > > > > > > > commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To > > > > > > > unsubscribe, e-mail: [email protected] For > > additional > > > > > > > commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > >
