ricardozanini commented on issue #298: URL: https://github.com/apache/incubator-kie-kogito-serverless-operator/issues/298#issuecomment-1802600260
The idea here is to have the `SonataFlow` controller follow the changes on `ConfigMaps` and `Secrets` mounted to the workflow `Deployment` object. Any time a `ConfigMap` or `Secret` attached to the `Deployment` is changed, the operator should roll out the deployment so the application can be restarted. Another approach is to send a signal to the pod to restart the app, so the configuration is refreshed. Quarkus won't refresh the application properties if the process is not restarted. I vote for restarting the app instead of rolling out the pod since it's faster. The file system is already updated by k8s. Another line is to research with the Quarkus community if this is the expected behavior since I can see this use case being useful there. We should look up the Microprofile Config component community. If the properties file/environment is updated, so will the app. The Environment variable is not a problem since it will change the deployment, hence a new rollout will be performed automatically by k8s. Envs from `Secrets` and `ConfigMaps` might be a problem, though. An implementation idea is to add the controller as one of the owners of the attached configs, so when the target object is updated, the controller is notified. We can then compare the generation, and if it has changed, we then rollout/restart the app. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
