https://flyte.org logo
#ask-the-community
Title
# ask-the-community
a

Andrew Achkar

01/13/2023, 9:45 PM
Hi there, I am wondering if there is a way to dynamically set the default inputs of a launchplan after it has been serialized and I only have access to the archive of serialized artifacts and flytectl. The use case is that I've generated workflow / launchplan artifacts in a CI process but now want to register those files on flyte running in different environments where the default inputs could be environment specific without having to re-package everything (just tweak the inputs to the launchplans). More details in 🧵
y

Yee

01/13/2023, 9:45 PM
@Prafulla Mahindrakar do you know if flytectl can create additional launch plans?
a

Andrew Achkar

01/13/2023, 9:46 PM
I see
flytectl register files
already handles something like this for some specific launchplan parameters:
Copy code
--assumableIamRole string       Custom assumable iam auth role to register launch plans with.
      --k8sServiceAccount string      Custom kubernetes service account auth role to register launch plans with.
      --outputLocationPrefix string   Custom output location prefix for offloaded types (files/schemas).
but I would probably need something more generic for replacing the default inputs
y

Yee

01/13/2023, 9:46 PM
i feel like it cannot… though I don’t know/remember why
a

Andrew Achkar

01/13/2023, 9:48 PM
Alternatively, is there some way to translate the launchplans from protobuf binary to yaml and back after making some modifications?
yeah you can maybe write something… i’m wondering though if there’s broader functionality that can be added to flytectl.
certainly i think you should be able to create a launchplan off of an existing workflow.
p

Prafulla Mahindrakar

01/13/2023, 10:06 PM
Flytectl lacks the create launch plan functionality currently. It doesn’t call into this API https://github.com/flyteorg/flyteidl/blob/master/protos/flyteidl/service/admin.proto#L141 and seems that could solve this case .
y

Yee

01/13/2023, 10:06 PM
was there a reason we didn’t do it? no right?
just didn’t get to it
p

Prafulla Mahindrakar

01/13/2023, 10:07 PM
yeah seems we never got to it . there is an old issue for it https://github.com/flyteorg/flyte/issues/392
y

Yee

01/13/2023, 10:07 PM
ic
thanks
@Andrew Achkar i don’t suppose this is something you’d be willing to contribute?
a

Andrew Achkar

01/13/2023, 11:12 PM
Ah interesting. Unfortunately I cannot contribute to OSS at this time. (working on it...) I think if there was an flytectl command to translate the serialized workflow/tasks/launchplan objects from/to protobuf/yaml that may find some general utility.
I think with immutability guarantees of flyte, changing the launchplan after its been registered at a specific version also wouldn't be an option, I presume.
Is the
assumableIamRole
value something we can retrieve in the context of a running task, to pass it to a different aws service for example?
y

Yee

01/23/2023, 6:02 PM
sorry can you elaborate more?
you can technically do an sts get-caller-identity during a task of course. though i’m not sure that’s the right thing to do.
so in eks you typically assign the workflow/launch plan to a k8s service account. that service account is hooked up to an iam role through the cluster
if you provide a role directly, I believe the node needs the ability to assume that role.
which will also show up in the sts call.
taking a look at the env vars that are mounted in, here’s a typical pod
Copy code
- name: FLYTE_INTERNAL_EXECUTION_WORKFLOW
      value: flytesnacks:development:backfiller.example_wf
    - name: FLYTE_INTERNAL_EXECUTION_ID
      value: fdaqqjwlxr2asu
    - name: FLYTE_INTERNAL_EXECUTION_PROJECT
      value: flytesnacks
    - name: FLYTE_INTERNAL_EXECUTION_DOMAIN
      value: development
    - name: FLYTE_ATTEMPT_NUMBER
      value: "0"
    - name: FLYTE_INTERNAL_TASK_PROJECT
      value: flytesnacks
    - name: FLYTE_INTERNAL_TASK_DOMAIN
      value: development
    - name: FLYTE_INTERNAL_TASK_NAME
      value: <http://backfiller.tk|backfiller.tk>
    - name: FLYTE_INTERNAL_TASK_VERSION
      value: XG5F3Qb38LZdh7Y86ImmBQ==
    - name: FLYTE_INTERNAL_PROJECT
      value: flytesnacks
    - name: FLYTE_INTERNAL_DOMAIN
      value: development
    - name: FLYTE_INTERNAL_NAME
      value: <http://backfiller.tk|backfiller.tk>
    - name: FLYTE_INTERNAL_VERSION
      value: XG5F3Qb38LZdh7Y86ImmBQ==
    - name: AWS_METADATA_SERVICE_TIMEOUT
      value: "5"
    - name: AWS_METADATA_SERVICE_NUM_ATTEMPTS
      value: "20"
    - name: AWS_DEFAULT_REGION
      value: us-east-2
    - name: AWS_REGION
      value: us-east-2
    - name: AWS_ROLE_ARN
      value: arn:aws:iam::123123:role/development-service-flyte-userflyterole
    - name: AWS_WEB_IDENTITY_TOKEN_FILE
      value: /var/run/secrets/eks.amazonaws.com/serviceaccount/token
don’t quite remember who mounts in that aws_role_arn, i can dig if you want.
but the tricky bit i think is the passing it on.
that might get complicated very quickly.
a

Andrew Achkar

01/23/2023, 6:19 PM
ok, yeah I arrived at something like this just poking around myself - I think the AWS_ROLE_ARN is just the value of the arn for the service account, regardless of whether an iam role is given in the security context. I think that IAM role in the security context is one that backend plugins use to submit requests to AWS services like sagemaker, batch
I was wondering if flytekit python plugins could access the same value
the IAM role arn seems to be just on the k8s pod annotations, which I am not sure if we can read
y

Yee

01/23/2023, 7:28 PM
a flytekit python plugin will be run with the same role yeah. since it’s just another python container that the flyte engine kicks off.
it’ll just be run with the same service account and iam role.
this is not true of backend plugins, or other plugins (like sql query plugins)
but for python containers it is
a

Andrew Achkar

01/23/2023, 7:37 PM
Yup, ok thx.
This also affects say image names. Once your package has been built, your image names are all static. Say we have the same exact workflow we want to deploy to flyte clusters in different regions / aws accounts. We cannot substitute the image registry for a different region, so deploying it that way would cause a cross-region pull. I wonder if there would be any way to support serialization to yaml or json rather than protobuf in the archive produced by
pyflyte package
, at least then we might be able to write simple tooling to do substitutions. Alternatively, if we produce an intermediate template (like a helm template or a cfn template) that at registration time (
flytectl register file
) could take values to substitute, I think that would be very handy.
11 Views