Reloading/updating rules in a deployed Kogito application

[Maëlle Hardouin]

Hello everyone !

We’ve been looking at Kogito and wondering if it could apply to our use case in a Kubernetes cloud environment. One thing we noticed is the unability to reload/update rules dynamically once a service is deployed. In development we can use quarkus hot reloading functionnality which is really handy, but it seems that we do not have that functionnality once deployed.

In production this means that we must:
• Build and deploy through CI to rebuild our application.
• Create a new image containing our application and update the deployment with Kubernetes.

In a development chain, this is not really an issue. However, in a production environment or customer application, it is not easy to have this process which can take time and is less conducive to this type of environment. Knowing that other tools like OPA or even Drools for example, allow this hot reloading, why does Kogito not allow it? Are there plans to have an opening for this functionality?  And if that’s not the case, is there a workaround to get us closer to a functioning like Drools?

Thank you in advance for your help !

[Gustavo Lent]

Hello!

No, I dont think that this is possible - because the DMN must be "parsed" to java code when deploying.

In the projects that we are using kogito we stucked at this, and we are currently moving out of kogito, because it's not possible to manage the rules and give them to a non-tech user

[Rhett S]

(it is my day off, responding quick. please excuse brevity)

what you are asking for is possible in drools. 

however, it is not possible in the kogito project. why? answer: it was a design decision. what was the intent of the decision? my understanding is the drools library using reflection. the kogito team wanted to support spring and quarkus releases. Quarkus is designed to avoid using reflection during start-up to reduce time. thus, the code that uses reflection requires the list of DMNs to be hardcoded in the constructed container. The Kogito team decided to use the same code for spring and quarkus flavors. thus, Kogito does not support hot-loading. 

kogito uses code gen. if you compile kogito, then disable code gen, then delicately move the generated code from target back to src, you will see how kogito restricts hot loading: the loading of the DMNs is in a static block.

https://github.com/x1c1cle/public-static-kogito-dmn/blob/main/src/main/java/org/kie/DecisionModels.java#L24

continuing to use kogito + code-gen will force the technical constraints on you.

you can change the code in the static block to dynamically load DMNs from ftp, database, or blob/s3. and all you need to do is restart your container in production. (not deploy!) this works. it is faster than a deploy, but slower than hotswapping. at enterprise scale (say, 3,000 DMNs across 90 containers constantly scaling, frequently reloading for updated DMNs) the design starts to show its weaknesses.

if you want total hotswapping/loading, you'll need to build your own drools dmn engine. 

[Maëlle Hardouin]

Hello, thank you for your help and insights !