@ancient-wolf-19325 How can inject labels to an execution based on a user's GCP account?

You can inject labels into a Flyte execution by specifying them at launch time or in the launch plan, using the

Labels

class in Python or via CLI options. These labels can include user-specific information, such as a GCP account, if you pass that data as part of the execution request. For example, you can do this programmatically:

from flytekit import Labels

my_launch_plan.execute(
    labels=Labels({"gcp_user": "<user_gcp_account_email>"}),
    ...
)

or via CLI:

pyflyte run --labels '{"gcp_user": "user@example.com"}' ...

See workflow labels and annotations documentation for details. However, Flyte does not automatically extract or inject the GCP account of the user launching the execution; you must provide this value explicitly when triggering the execution. There is no built-in mechanism in the provided data sources to auto-populate labels from GCP user identity. Would you like more detail on how to automate passing the GCP account, or on how to retrieve user identity in Flyte executions? Sources: - workflow labels and annotations documentation 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 can I do this based on project

Yes, you can inject labels at the Flyte project level so that all executions within a project automatically inherit those labels. This is done by setting project labels using

flytectl

or via project configuration, and these labels will be applied to all executions in that project unless overridden at a more specific level. For example:

flytectl update project --name my-project --id my-project --labels app=flyte,gcp_user=user@example.com

or by specifying labels in a YAML file and applying it with

flytectl

as described in project label documentation. Would you like more detail on how project-level labels interact with workflow or execution-level labels? Sources: - Project label update example 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 I already ran. But the executions in the (my_team, dev) domain still don't have labels flytectl update project -p my_team --labels team=my_team

It seems likely that updating project labels with

flytectl update project -p my_team --labels team=my_team

will only affect new executions after the update, not those already running or completed. Existing executions in the (my_team, dev) domain will not retroactively receive the new label, as labels are attached at execution creation time according to project label update logic and label propagation behavior. If you need labels on past executions, there is no built-in way to retroactively add them; you would need to re-run those executions after updating the project labels. Would you like more detail on how label inheritance works or how to verify label propagation? Sources: - project label update logic - label propagation behavior 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 even after I apply the project labels. pyflyte run remote executions in (project, domain) still don't have the label

Project labels set via

flytectl update project

are not automatically propagated as execution labels to workflow executions created with

pyflyte run

. Execution labels must be explicitly set at execution or launch plan level; project labels are metadata on the project and do not auto-inject into execution-level labels or Kubernetes pod labels by default, as confirmed in label propagation behavior and project label update logic. To ensure executions have specific labels, you must pass them directly when launching with

pyflyte run

using the

--labels

flag or set them in the launch plan. There is no built-in mechanism in Flyte to auto-inherit project labels as execution labels. Would you like more detail on how to automate label injection or on the distinction between project and execution labels? Sources: - label propagation behavior - project label update logic 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.