https://flyte.org logo
Join Slack
Powered by
how can i get workflow metadata at runtime these d...
# flytekit
d
how can i get workflow metadata at runtime these days? project, domain, workflow, task, version etc
p
you can get this using the get workflow admin api. eg : following command get this info
Copy code
flytectl get workflow -p flytesnacks -d development   core.flyte_basics.lp.go_greet --latest -o yaml
d
probably not the pattern we want to use from a task though right? anyway to grab from flytekit?
like the current context
related question: is it possible to inject env vars into workflows at launch time
found this. is it meant to be public?
s
It should be accessible.
d
where? it used to be 
flytekit.configuration.internal.DOMAIN
p
@Dylan Wilder this should be available to the user pod through these env var’s
Copy code
FLYTE_INTERNAL_EXECUTION_WORKFLOW:  flytesnacks:development:<http://example.wf|example.wf>
      FLYTE_INTERNAL_EXECUTION_ID:        a2r6nshjwvt8x54lp4c2
      FLYTE_INTERNAL_EXECUTION_PROJECT:   flytesnacks
      FLYTE_INTERNAL_EXECUTION_DOMAIN:    development
      FLYTE_ATTEMPT_NUMBER:               0
      FLYTE_INTERNAL_TASK_PROJECT:        flytesnacks
      FLYTE_INTERNAL_TASK_DOMAIN:         development
      FLYTE_INTERNAL_TASK_NAME:           example.generate_normal_df
      FLYTE_INTERNAL_TASK_VERSION:        O_YLNJX3tLNuJdNrP4WbdQ==
      FLYTE_INTERNAL_PROJECT:             flytesnacks
      FLYTE_INTERNAL_DOMAIN:              development
      FLYTE_INTERNAL_NAME:                example.generate_normal_df
      FLYTE_INTERNAL_VERSION:             O_YLNJX3tLNuJdNrP4WbdQ==
Every pod created by flyte would have these env variables which you can use for detecting the runtime workflow meta
re :
Copy code
found this. is it meant to be public?
This is used during registration and not consumed elsewhere
d
awesome! that's what i was looking for
k
@Dylan Wilder these are internal and meant to change, as we are working on compressing them. But which ones do you want
Most have been added to the context now
d
need, project, domain, workflow, version, exec id
feel like these should be part of some public api, i had expected to see them in the flyte context so that probably makes sense
many, many use cases but • need to differentiate prod /non-prod resource management • need to associate resources with specific production metadata
can i get more detail on the diff between EXECUTION* and TASK* vars
EXECUTION is the value of the parent workflow?
p
Cc : @Yee
y
the difference is that it’s technically possible to launch a task in project a, under project b
so execution in this case would be b, but task_ would be a
d
and what about 
FLYTE_INTERNAL_*
also, are any of these available at registration?
y
what were you thinking (wrt registration)?
the short answer is no… because registration is a two step process. the definition of the task (and all other entities) is compiled with those placeholders. the task template also includes the env vars.
only when those protobufs are sent up to admin, are the placeholders replaced.
i think the public api that we add under context will end up using those 
INTERNAL_
environment variables yes. the container plugin adds them.
g
We use the 
FLYTE_INTERNAL_EXECUTION_DOMAIN
env var currently within tasks/workflows to configure environment specific external service urls
k
@Gigi I think we should starting using all of this from the context
👍 1
we want to have the flexibility to modify 
INTERNAL
to improve performance etc
g
It's not currently in context, right? When it's there we would do something like 
flytekit.current_context().domain
or something?
k
yup
that would be perfect
cc @Yee?
y
yeah we can make a ticket for this
can you put the interface you want to see here @Dylan Wilder? https://github.com/flyteorg/flyte/issues/2490
167 Views
Open in Slack
PreviousNext
Powered by