You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the deprecation of templates, there are some flaws arising with the only use of Subflow:
It doubles the number of execution. With templates, tasks were passed directly in the flow, like if they were written directly inside it. Before 1 flow = 1 exec. Now with subflow 1 flow = 2 exec. Making the executions lists overwhelming in the UI.
Some users track billing information, with 1 namespace = 1 project. Using subflow here kind of make this billing wrong as one subflow can be used in many namespaces (so there is an overlap sometimes in the executions).
Subflow have to be in the same namespace to have access to the same right (service account)
Possible Solutions
For the execution problem (1. & 2.):
can be handle with labels or filtering: bring a flag subflow on the flow, that allow to hide subflow from the list
add a included:true property to the io.kestra.core.tasks.flows.Flow :
id: "flow"type: "io.kestra.core.tasks.flows.Flow"namespace: devflowId: subflowinputs:
user: "Rick Astley"favorite_song: "Never Gonna Give You Up"wait: truetransmitFailed: trueincluded: true
Without this kind of flag, currently the flow will create two executions: one for the main flow, one for the subflow. The included property let the user to choose if the subflow can be "included" directly in the subflow - merging the old template behaviour into the subflow one; i.e. having only one execution for the thing.
Hiding subflows from the UI (a dedicated filter property showing whether some execution is a subflow execution or not) is something we can definitely add: #2559
Regarding a secret/service account as input property, you're spot on, we will do it as part of that linked issue.
I worry about not creating a proper child execution for a subflow. E.g. how would it look like when such a subflow would be used on the ForEachItem? It may lead to many issues. Let's handle these two at first.
Feature description
Problem
With the deprecation of templates, there are some flaws arising with the only use of Subflow:
It doubles the number of execution. With templates, tasks were passed directly in the flow, like if they were written directly inside it. Before 1 flow = 1 exec. Now with subflow 1 flow = 2 exec. Making the executions lists overwhelming in the UI.
Some users track billing information, with 1 namespace = 1 project. Using subflow here kind of make this billing wrong as one subflow can be used in many namespaces (so there is an overlap sometimes in the executions).
Subflow have to be in the same namespace to have access to the same right (service account)
Possible Solutions
included:true
property to theio.kestra.core.tasks.flows.Flow
:Without this kind of flag, currently the flow will create two executions: one for the main flow, one for the subflow. The
included
property let the user to choose if the subflow can be "included" directly in the subflow - merging the old template behaviour into the subflow one; i.e. having only one execution for the thing.The text was updated successfully, but these errors were encountered: