Let’s say we have a workflow that should be associated with N different inputs, entailing N different launch plans. How would you structure/manage this in code? We have adopted an idea of managing the launch plans in a separate folder, next to the flyte workflows and thus deploying the launch plans and workflow in separate - see example below. Does this make sense for the N:1 relationship between launch plans and workflows? This entails a lot of duplication of boilerplate code in

lp.py

but it is maybe the cleanest solution to this problem?

(.venv) ☁  flyte [main] tree .
.
├── <http://in_container.mk|in_container.mk>
├── launchplans
│   └── lp.py
└── workflows
    ├── wf.py

I’m probably missing something, what is the boilerplate that ends up getting duplicated?

Oh right, I forgot to add that code snippet. So

lp.py

then is

# imports

lp_definition_use_case_1
...
lp_definition_use_case_N

If I change launchplan_i, then I would need to re-deploy all launch plans. But maybe that’s fine?

@Hampus Rosvall, you can use

pyflyte register

for

lp.py

as well:

pyflyte register lp.py

, without sending an

--image

argument if you’re okay with using the latest flytekit image.

@Samhita Alla I have already deployed my workflow using

--image

flag. What does it entail to deploy launch plans using the latest flytekit image then?

I don’t think an

--image

flag is required cause a launch plan executes a workflow of specific version which might have already been associated with an image (in your case).

Gotcha, thanks for your help! So it makes sense then?

Yeah!

The launch plan definition below deploys a new launch plan, but also the entire workflow using

pyflyte register flyte/launchplans/lp.py

- is there a way to only deploy a launch plan that runs the latest version of a workflow without deploying a new workflow version? What is best practice in terms of working with launch plans?

from flytekit import LaunchPlan
from ..workflows import wf

LaunchPlan.get_or_create(
    workflow=<http://wf.wf|wf.wf>,
    name="flytesnacks_lp",
    default_inputs={},
)

The workflow’s getting registered cause you’re importing it. I’m not sure how to register only a launch plan. @Yee @Eduardo Apolinario (eapolinario), is that possible today?

I am just after some guidelines in terms of how I should think about working with launch plans. To me it seems like it is considered best practice to register launch plans whenever you register a workflow. If that is the preferred way then that is all good! 🙂

Yeah! That seems like a better way, although you should be able to register a launch plan without registering a workflow. I think this should be possible through FlyteRemote’s `register_launch_plan`: https://docs.flyte.org/projects/flytekit/en/latest/design/control_plane.html#registering-entities; I’m not pretty sure, though.