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.

just didn’t get to it

thanks

@Andrew Achkar i don’t suppose this is something you’d be willing to contribute?

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?

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

- 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.

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

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

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.