jordigilh commented on PR #311: URL: https://github.com/apache/incubator-kie-kogito-serverless-operator/pull/311#issuecomment-1858127112
> Hi @jordigilh > > > in other words: the properties specific for creating the job service are all included in the properties for a sonataflow CR? or a subset of those? > > > Right now I consider them to be the same. > > No, they are not the same. I think it was there that things messed a little bit. Take a look at this repo we shared at the beginning of the development: > > https://github.com/flows-examples/techpreview2/tree/main/infra/dataindex_and_jobservice > > You can see the JS Deployment and the `application.properties` for it there. That's exactly what we were expecting for this PR to do. > > And then, if you see the use case: https://github.com/flows-examples/techpreview2/tree/main?tab=readme-ov-file#use-case-3 > > It's explained there how it is supposed to be working. The workflow has yet another set of properties: https://github.com/flows-examples/techpreview2/blob/main/workflows/sonataflow-callbackstatetimeouts-persistence/02-configmap_callbackstatetimeouts-props > > That's why I asked to separate the props in the first place last week between the services and the workflow. I thought it was clear since these use cases were already working and defined in that repo. I'm sorry if I made an incorrect assumption. Ok, so for the sake of clarity because I'm not yet sure what should be in where: * When deploying the job service alone, the properties that should go specific for the job service are as follows (just adding the key here for simplicity): * `kogito.service.url` * `quarkus.datasource.jdbc.url` * `quarkus.datasource.reactive.url` * `kogito.jobs-service.http.job-status-change-events` * `mp.messaging.outgoing.kogito-job-service-job-status-events-http.url` * `quarkus.smallrye-health.check."org.kie.kogito.jobs.service.messaging.http.health.knative.KSinkInjectionHealthCheck".enabled` * When Data Index is deployed with a nonDev profile and with the enabled field set to `true`, additional properties to be added: * `kogito.jobs-service.http.job-status-change-events` * `mp.messaging.outgoing.kogito-job-service-job-status-events-http.url` * When deploying a workflow, these are the keys expected generated by the job service with a postgreSQL DB for persistence: * `mp.messaging.outgoing.kogito-job-service-job-request-events.connector` * `mp.messaging.outgoing.kogito-job-service-job-request-events.url` I can't find any property shared between the job service deployment and a workflow deployment. From the [application.properties](https://github.com/flows-examples/techpreview2/blob/main/workflows/sonataflow-callbackstatetimeouts-persistence/02-configmap_callbackstatetimeouts-props.yaml) in the example @ricardozanini provided, I can see only 3 of the 4 properties that @wmedvede mentioned earlier in the case of deployment of a workflow: one listed in the job service section and the other 2 outside of it, which would mean they're out of scope of this PR:` kogito.events.usertasks.enabled`, `kogito.events.variables.enabled`. Missing is `kogito.events.processdefinitions.enabled`. Is this configuration correct? -- 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]
