[BUG] LaunchPlan cannot be created within a function

[kumare3]

Describe the bug

Launchplans do not really need to be tracked as they do not exist during runtime. It should be possible to use launchplans without an LHS reference. But currently this fails, with an error like

def _task_module_from_callable(f: Callable):
        mod = inspect.getmodule(f)
        mod_name = getattr(mod, "__name__", f.__module__)
>       name = f.__name__.split(".")[-1]
E       AttributeError: 'LaunchPlan' object has no attribute '__name__'

Expected behavior

Ideally it should be possible to create Launchplan.create and use it inline programmatically

Additional context to reproduce

It should also be possible to use lps in jupyter

Screenshots

No response

Are you sure this issue hasn't been raised already?

• Yes

Have you read the Code of Conduct?

• Yes

[kumare3]

There might be a few cases where __name__ attribute is not provided, but ideally all lps should have a human defined name and it is ok to use the tracker in the absence to maintain backwards compatiblity

[adrianloy]

We are also running into this when updating flytekit to 1.14.0. I am passing an object of type flytekit.core.launch_plan.LaunchPlan to remote.register_launch_plan which I would assume should work, but fails with the exception mentioned in this issue. If I inspect my launchplan object, I see that it has a name attribute but not a __name__ attribute.

[kumare3]

Cc @eapolinario ?

[wild-endeavor]

In testing flyteorg/flytekit#3043 noticed that it was actually a little bit difficult. The issue can be illustrated by something like

let's say in the past my_wf has already been registered with version ksD2LBYDu5PrNtNnnpd95Q

from wfs import my_wf

lp = LaunchPlan.get_or_create(workflow=my_wf, name="other_lp_for_hello2", default_inputs={})
remote = FlyteRemote(...)
remote.register_launch_plan(entity=lp, version="ksD2LBYDu5PrNtNnnpd95Q")
...

The issue is that register_launch_plan will currently try to register the underlying workflow again. This would be fine, except that the serialization settings that are used may be completely different. Even if it's exactly the same, this is a waste of time because the best case scenario is that Admin returns already exists for the workflow and every underlying task (and subwf, etc.).

We should check first to see if the workflow already exists with that version, and only register the launch plan if the workflow already exists.

Skipping re-registration of the workflow does mean that users who were relying on this re-registration (and were somehow reconstructing serialization settings to be identical) to detect changes in workflow/task structure will no longer see errors, but that seems too far-fetched.