Thanks for the explanation, Francisco! Cheers! On Thu, Mar 5, 2026 at 5:12 PM Francisco Javier Tirado Sarti < [email protected]> wrote:
> 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] > > > > > > > > > > > > > > > > > > > >
