flyteorg
[BUG] `default_project` is not used when using `register_launch_plan` method.
Describe the bug
from flytekit import CronSchedule, LaunchPlan # noqa: E402
from train_model_workflow import train
from flytekit.remote import FlyteRemote
from flytekit.configuration import Config
remote = FlyteRemote(
config=Config.auto(config_file="../config.yaml"),
default_project="flytesnacks",
default_domain="development",
)
cron_lp = LaunchPlan.get_or_create(
name="train-cron",
workflow=train,
schedule=CronSchedule(
schedule="*/5 * * * *",
),
)
remote.register_launch_plan(
cron_lp,
version="1707810374",
)
When I execute this, I get an error,
❯ python cron.py
╭────────────────── Traceback (most recent call last) ───────────────────╮
│ /Users/foo/work/pipelines/venv/lib/python3.11/site-pac │
│ kages/grpc/_interceptor.py:315 in continuation │
│ │
│ ❱ 315 │ │ │ │ response, call = self._thunk(new_method).with_ca │
│ │
│ /Users/foo/work/pipelines/venv/lib/python3.11/site-pac │
│ kages/grpc/_interceptor.py:343 in with_call │
│ │
│ ❱ 343 │ │ return self._with_call( │
│ │
│ /Users/foo/work/pipelines/venv/lib/python3.11/site-pac │
│ kages/grpc/_interceptor.py:332 in _with_call │
│ │
│ ❱ 332 │ │ return call.result(), call │
│ │
│ /Users/foo/work/pipelines/venv/lib/python3.11/site-pac │
│ kages/grpc/_channel.py:437 in result │
│ │
│ ❱ 437 │ │ raise self │
│ │
│ /Users/foo/work/pipelines/venv/lib/python3.11/site-pac │
│ kages/grpc/_interceptor.py:315 in continuation │
│ │
│ ❱ 315 │ │ │ │ response, call = self._thunk(new_method).with_ca │
│ │
│ /Users/foo/work/pipelines/venv/lib/python3.11/site-pac │
│ kages/grpc/_interceptor.py:343 in with_call │
│ │
│ ❱ 343 │ │ return self._with_call( │
│ │
│ /Users/foo/work/pipelines/venv/lib/python3.11/site-pac │
│ kages/grpc/_interceptor.py:332 in _with_call │
│ │
│ ❱ 332 │ │ return call.result(), call │
│ │
│ /Users/foo/work/pipelines/venv/lib/python3.11/site-pac │
│ kages/grpc/_channel.py:437 in result │
│ │
│ ❱ 437 │ │ raise self │
│ │
│ /Users/foo/work/pipelines/venv/lib/python3.11/site-pac │
│ kages/grpc/_interceptor.py:315 in continuation │
│ │
│ ❱ 315 │ │ │ │ response, call = self._thunk(new_method).with_ca │
│ │
│ /Users/foo/work/pipelines/venv/lib/python3.11/site-pac │
│ kages/grpc/_channel.py:1177 in with_call │
│ │
│ ❱ 1177 │ │ return _end_unary_response_blocking(state, call, True, │
│ │
│ /Users/foo/work/pipelines/venv/lib/python3.11/site-pac │
│ kages/grpc/_channel.py:1003 in _end_unary_response_blocking │
│ │
│ ❱ 1003 │ │ raise _InactiveRpcError(state) # pytype: disable=not-i │
╰────────────────────────────────────────────────────────────────────────╯
_InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
status = StatusCode.INVALID_ARGUMENT
details = "missing project"
debug_error_string = "UNKNOWN:Error received from peer
{created_time:"2024-02-13T16:56:18.227687+05:30", grpc_status:3,
grpc_message:"missing project"}"
>
The above exception was the direct cause of the following exception:
╭────────────────── Traceback (most recent call last) ───────────────────╮
│ /Users/foo/work/pipelines/flyte/my_workflow/cron.py:21 │
│ in <module> │
│ │
│ ❱ 21 remote.register_launch_plan( │
│ │
│ /Users/foo/work/pipelines/venv/lib/python3.11/site-pac │
│ kages/flytekit/remote/remote.py:974 in register_launch_plan │
│ │
│ ❱ 974 │ │ │ self.client.create_launch_plan(ident, idl_lp.spec) │
│ │
│ /Users/foo/work/pipelines/venv/lib/python3.11/site-pac │
│ kages/flytekit/clients/friendly.py:333 in create_launch_plan │
│ │
│ ❱ 333 │ │ super(SynchronousFlyteClient, self).create_launch_plan( │
│ │
│ /Users/foo/work/pipelines/venv/lib/python3.11/site-pac │
│ kages/flytekit/clients/raw.py:274 in create_launch_plan │
│ │
│ ❱ 274 │ │ return self._stub.CreateLaunchPlan(launch_plan_create_re │
│ │
│ /Users/foo/work/pipelines/venv/lib/python3.11/site-pac │
│ kages/grpc/_interceptor.py:277 in __call__ │
│ │
│ ❱ 277 │ │ response, ignored_call = self._with_call( │
│ │
│ /Users/foo/work/pipelines/venv/lib/python3.11/site-pac │
│ kages/grpc/_interceptor.py:329 in _with_call │
│ │
│ ❱ 329 │ │ call = self._interceptor.intercept_unary_unary( │
│ │
│ /Users/foo/work/pipelines/venv/lib/python3.11/site-pac │
│ kages/flytekit/clients/grpc_utils/wrap_exception_interceptor.py:44 in │
│ intercept_unary_unary │
│ │
│ ❱ 44 │ │ │ │ │ raise e │
│ │
│ /Users/foo/work/pipelines/venv/lib/python3.11/site-pac │
│ kages/flytekit/clients/grpc_utils/wrap_exception_interceptor.py:40 in │
│ intercept_unary_unary │
│ │
│ ❱ 40 │ │ │ │ │ self._raise_if_exc(request, e) │
│ │
│ /Users/foo/work/pipelines/venv/lib/python3.11/site-pac │
│ kages/flytekit/clients/grpc_utils/wrap_exception_interceptor.py:30 in │
│ _raise_if_exc │
│ │
│ ❱ 30 │ │ │ │ raise FlyteInvalidInputException(request) from e │
╰────────────────────────────────────────────────────────────────────────╯
FlyteInvalidInputException
Expected behavior
default_project should be used when registering a launch plan.
Additional context to reproduce
No response
Screenshots
No response
Are you sure this issue hasn't been raised already?
- [X] Yes
Have you read the Code of Conduct?
- [X] Yes
🤖
Hey @debajyoti-truefoundry, great to see you here again! Running into a bit of a snag, huh? Let's dive in and see if we can untangle this issue together.
Based on the code you've shared, it seems like the default_project you've set during the initialization of FlyteRemote is not being used when registering the launch plan. This could be the reason why you're encountering a "missing project" error.
In the Flyte codebase, the creation of a launch plan, which could be considered as a registration process, is handled by the CreateLaunchPlan method in the LaunchPlanManager struct. This method is tested in the TestCreateLaunchPlan function. However, the default_project and default_domain parameters are not explicitly handled in this function.
To resolve this issue, you could modify the function that creates the launch plan to use the default_project instead of the hardcoded project. Here's an example of how you can modify the function:
func getLaunchPlanCreateRequest(workflowIdentifier *core.Identifier, defaultProject string) admin.LaunchPlanCreateRequest {
return admin.LaunchPlanCreateRequest{
Id: &core.Identifier{
ResourceType: core.ResourceType_LAUNCH_PLAN,
Project: defaultProject,
Domain: "development",
Name: "name",
Version: "version",
},
Spec: &admin.LaunchPlanSpec{
WorkflowId: workflowIdentifier,
DefaultInputs: &core.ParameterMap{
Parameters: map[string]*core.Parameter{
"foo": {
Var: &core.Variable{
Type: &core.LiteralType{Type: &core.LiteralType_Simple{Simple: core.SimpleType_STRING}},
},
Behavior: &core.Parameter_Default{
Default: coreutils.MustMakeLiteral("foo-value"),
},
},
},
},
},
}
}
In this modified function, defaultProject is a new parameter that should be the project set during the initialization of FlyteRemote. This way, the launch plan will be created with the correct project.
Please note that this is a potential solution based on the provided context and the available information in the Flyte repository. If this doesn't resolve your issue, could you please provide more details about your setup and the steps you're following? This will help in understanding the issue better and finding a more accurate solution.
Sources
About Dosu
This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.
Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.
If you want to continue the conversation, start your reply with @dosu-bot.
![dosubot[bot] avatar](https://avatars.githubusercontent.com/in/324583?v=4 "Published by a pub.dev verified publisher"){kind=small}
