ricardozanini opened a new issue, #488: URL: https://github.com/apache/incubator-kie-kogito-serverless-operator/issues/488
### Description Currently, the `SonataFlow` CR specification only allows one workflow definition in the `.spec.flows` attribute. For users to use subflows they would need to create a specialized `ConfigMap` in the `.spec.resources` attribute so then the operator can mount these workflows in the pod's volume. From there, users can call these subflows from the main definition in `.spec.flow`. The current approach presents the following drawbacks: - Subflows are not tracked by the operator, hence no Knative objects or service discovery bindings are processed. This limits what users can do with sub flows; - Subflows can not be called externally via HTTP REST calls - Users must create a separate object (ConfigMap) to have them in the context - If a sub flow also acts as a normal flow, the user will have to deploy it twice in the cluster (one as a CM and a copy of it in the SonataFlow CR) ### Implementation ideas To overcome the outlined drawbacks, we will introduce the `.spec.flows` which will hold an array of workflow definitions deployed together in a single pod, enabling users to call them internally as sub-flows or externally as they were common flows deployed in the architecture. `.spec.flows` and `.spec.flow` can be defined at the same time. ## Impacts @treblereel This will impact the kn-cli manifest generation since we will drop CM support for subflows. There won't be a concept of "main" flow anymore. @fantonangeli this may impact the UI, can you do an assessment? @handreyrc This will for sure impact the integration with the Orchestrator. I'm unsure if the plugin is considering one workflow per deployment unit. cc @masayag to assess and help evaluating on Backstage, this is a requirement for https://github.com/apache/incubator-kie-issues/issues/1181. @fjtirado fyi -- 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]
