Currently in BPMS, what to deploy is configured in the system.git
internal repo (or in Pfp with kie.deployments.json), but this only kicks
in when the server starts up.
If you deploy or undeploy in BPMS, it leverages CDI events to have the
deployment triggered by the deployment service. But that won't work in a
distributed setup.
Hence my thinking of using Zookeeper or something like that to keep
deployments in sync over a cluster of exec servers.
So you would trigger deployment of a new kjar on one node (let's say
over a REST interface). On that node, the deployment configuration file
would be updated to reflect the new deployment. On the other nodes, the
deployment configuration file is updated as well through Zookeeper, so
the new deployment can be picked up on those nodes as well.
Currently in BPMS, what to deploy is configured in the system.git internal repo (or in Pfp with kie.deployments.json), but this only kicks in when the server starts up. If you deploy or undeploy in BPMS, it leverages CDI events to have the deployment triggered by the deployment service. But that won't work in a distributed setup. Hence my thinking of using Zookeeper or something like that to keep deployments in sync over a cluster of exec servers. So you would trigger deployment of a new kjar on one node (let's say over a REST interface). On that node, the deployment configuration file would be updated to reflect the new deployment. On the other nodes, the deployment configuration file is updated as well through Zookeeper, so the new deployment can be picked up on those nodes as well.