In this task, we should be able to identify the possibilities and tradeoffs for combining multiple workflow definitions within the same SonataFlow CR.

Currently, we have:

apiVersion: sonataflow.org/v1alpha08
kind: SonataFlow
metadata:   
  name: greeting
  annotations:     
    sonataflow.org/version: 0.0.1
spec:   
  flow: 

So one SonataFlow deployment unit per workflow definition. This would deploy a new workflow instance at http://kubernetes.svc.local/greeting.

The problem with this approach is that the internal runtime allows multiple workflow definitions per deployment unit.

The outcome of this spike is a document detailing the implementation proposal. Either by collecting multiple SonataFlow CRs into one deployment unit or allowing multiple workflow definitions per SonataFlow CR.

Approach #1

One SonataFlow with multiple flow definitions per deployment unit.

apiVersion: sonataflow.org/v1alpha08
kind: SonataFlow
metadata:   
  name: greeting
  annotations:     
    sonataflow.org/version: 0.0.1
spec:   
  flows:      
    - flow: 

In this case, the CR can be quite complex and long. Might even break the etcd size limit.

Approach #2

SonataFlow collection per deployment unit.

apiVersion: sonataflow.org/v1alpha08
kind: SonataFlow
metadata:   
name: greeting
  annotations:     
    sonataflow.org/version: 0.0.1
    sonataflow.org/deploymentUnit: greeting
spec:   
  flow: 

SonataFlow CRs that match sonataflow.org/deploymentUnit annotation within the same namespace would be considered one deployment unit.

Both should support the new spec.subFlows attribute so users won't rely on ConfigMaps anymore [1]. The problem with the second approach is that we will need a specific descriptor to describe the deployment unit. See KOGITO-9265.

[1] - https://sonataflow.org/serverlessworkflow/1.42.0.Final/cloud/operator/referencing-resource-files.html