making this a top level thread for visibility slightly smili

Question

making this a top level thread for visibility slightly smiling face is it possible to inject env vars into workflows at launch time or to extend flyte context with user info

Yee · Answer

where would they come from

Dylan Wilder · Answer

you mean where would we inject them

Dylan Wilder · Answer

for context we d like to be able to pass environment to the tasks at runtime in order to distinguish between dev staging prod since we can run staging tasks in prod we can t necessarily rely on flyte env from the other thread

Yee · Answer

you just need to know the flyte admin domain for the execution

Yee · Answer

i think we can just use that flytekit config for now it s not a public api though so we ll add it to the context

Dylan Wilder · Answer

a better example that will make this clearer i need to inject the url of a service endpoint which may be different depending on where the workflow was launched

Dylan Wilder · Answer

since you can technically launch dev stagin prod workflows from anywhere ie the production flyte instance i can t rely on that to know if i should be hitting production databases or not

Yee · Answer

for the most part we try to avoid adding env vars at run time because that can violate reproducibility but this is the main situation where we would want to

Yee · Answer

but i think this just exposing the execution domain would be enough right

Yee · Answer

things that were launched into any project s production domain should hit the service s production endpoint right

Dylan Wilder · Answer

well what is execution domain the domain of the top level workflow

Yee · Answer

yeah

Yee · Answer

also fyi we ve impacted services at lyft because of large workflows hitting them before but i think those were run on aws batch so thousands of machines

Dylan Wilder · Answer

consider that we have a separate system which is external to flyte which has it s own staging prod tiers we want our users to only use the prod tier even if they re doing development but we still need an internal staging tier for ourselves so we need to determine which system we re running in irrespective of the flyte domain

Dylan Wilder · Answer

but yes i hear you about breaking referential transparency i think this is an exception

Yee · Answer

so when would you want flyte to inject what values what i mean is you can already configure flyte to add default env vars

Yee · Answer

Yee · Answer

but obviously this is static per flyte installation

Dylan Wilder · Answer

Launch time

Yee · Answer

why not make it an input

Dylan Wilder · Answer

could but that would result in a spaghetti code wherein every workflow task needs it

Yee · Answer

i still don t understand though if each flyte installation i don t know how many you have always tells each task the same environment you can just use the default env vars setting right

Yee · Answer

if any given flyte installation can tell tasks to use different service environments where does it get that information from and how is that decision made

Yee · Answer

does that make sense just trying to understand where the source of the information is coming from

Gigi · Answer

We would love to be able to keep something like a configmap with external service urls per environment which could be added to an envFrom on the execution pods in our flyte execution k8s cluster We currently key off the `FLYTE INTERNAL EXECUTION DOMAIN` and then are hardcoding external service urls in the workflow code for tasks which need to make calls out to other microservices If any of those change we have to update the workflows

Gigi · Answer

It seems unwieldy to specify as inputs

Gigi · Answer

For us we generally can map Flyte domain to our external services env

Gigi · Answer

Thanks for pointing out the default envs per propeller k8s plugin config We could probably use that and I was unaware of that feature

Yee · Answer

Yee · Answer

created that a couple days ago

Yee · Answer

mind adding your thoughts on there < Gigi> sorry i should ve posted it earlier

Yee · Answer

can you elaborate what you mean by per environment as well

Yee · Answer

you mean per flyte domain

Gigi · Answer

Happy to add thoughts to that discussion Our use case is a bit different than Dylan s in that our configured domains match our external service ecosystem environments so we generally want workflows in the development domain to use the development service ecosystem and matching service urls However we have a bunch of commonly used external services within various projects and workflows We would love a way to have something like a list of development service urls that could get injected for workflows in the development domain for a bunch of projects workflows Currently every project and workflow keys off the internal env var to get the domain and has a hard coded map of service urls for that domain ie `ZAUTH UTL` `ZREST URL` etc Mostly it s a lot of repeated boilerplate config that different project teams are maintaining We could put it in a Python lib to DRY it up a bit but it s the kind of thing we often put in configmaps in our other k8s ecosystems