Hey Flyte Community, we are considering some big a...
# flyte-support
s
Hey Flyte Community, we are considering some big architectural choices in Flyte, and I wanted to ask: how many of you are using multiple launch plans tied to the same workflow? I am specifically trying to answer the question of whether launch plans need to be separate entities at all, or whether the functionality (schedules, default inputs, etc) can simply live in the workflow interface. Thanks!
f
Cc @brief-window-55364 @cool-lifeguard-49380 @clean-glass-36808 @future-monitor-58430 your inputs will be valuable
c
Happy to talk @silly-toddler-37820
But I think for us the TL;DR is that we use launchplans 1. instead of subworkflows in some very large workflows to make sure that there aren’t too many nodes in a workflow (execution) to not overload the UI or run into other limitations. Basically, we rely on creating sub-executions. 2. To attach schedules to workflows
f
We use reference launch plans pretty heavily at LinkedIn (i think perhaps the reference workflows will also work for those cases if properly supported?) I am sure there are several patterns of our users using launch plans, but one notable pattern that I see is to reuse workflow across environments. For example, users may have different data paths, schedules, etc. for staging vs dev. They often will have a structure similar to this: • src/flows/workflow.py • src/flows/prod/launch_plan.py -- imports workflow, defines a launch plan, schedules it, notifications are sent to oncalls. • src/flows/dev/launch_plan.py -- imports workflows, defines a launch plan, no schedule, notifications are sent to the current user. cc: @careful-analyst-27506 as well.
c
+1 for Ankit's description above. We also use launchplans to associate different dataplanes/clusters for the same source workflow. Overall having launchplans as an distinct entity from workflows has been quite useful. Curiuos, what architectural changes did you have in mind ?
c
I haven’t looked into our code base deeply but we definitely reuse workflows across control Flyte installations like dev/prod as well extremely heavily.
s
Thank you all for the detailed feedback - in particular I love the example of using Launch Plans to facilitate the promotion of a workflow from dev to prod 🙂. That's a perfect use case for having multiple launch plans pointed to the same workflow.
Curious, what architectural changes did you have in mind ?
I was thinking that we could maybe combine the workflow and launch plan interfaces (i.e. add schedules to workflows directly, kick off subworkflows directly).
b
Don't think we have at Spotify have any big preference for us but we do use the launch plans heavily.
As entrypoints only for both local and remote. Usually we use the domains for dev developments and so on.