Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] default_project is not used when using register_launch_plan method. #4889

Closed
2 tasks done
debajyoti-truefoundry opened this issue Feb 13, 2024 · 2 comments
Closed
2 tasks done
Labels
bug Something isn't working flytekit FlyteKit Python related issue

Comments

@debajyoti-truefoundry
Copy link

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?

  • Yes

Have you read the Code of Conduct?

  • Yes
@debajyoti-truefoundry debajyoti-truefoundry added bug Something isn't working untriaged This issues has not yet been looked at by the Maintainers labels Feb 13, 2024
Copy link

dosubot bot commented Feb 13, 2024

🤖

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.

@pingsutw pingsutw added flytekit FlyteKit Python related issue and removed untriaged This issues has not yet been looked at by the Maintainers labels Feb 14, 2024
@wild-endeavor
Copy link
Contributor

thanks @ChungYujoyce!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working flytekit FlyteKit Python related issue
Projects
None yet
Development

No branches or pull requests

3 participants