Channels
#flytekit
Title
d
Dylan Wilder
05/02/2022, 3:35 PMmaking this a top level thread for visibility 🙂 is it possible to inject env vars into workflows at launch time? or to extend flyte context with user info?
y
Yee
05/02/2022, 4:59 PM
where would they come from?
d
Dylan Wilder
05/02/2022, 5:01 PMyou mean where would we inject them?
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
y
Yee
05/02/2022, 5:27 PM
you just need to know the flyte admin domain for the execution?
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.
d
Dylan Wilder
05/02/2022, 6:25 PMa 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
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
y
Yee
05/02/2022, 6:49 PM
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.
but i think this just exposing the execution domain would be enough right?
things that were launched into any project’s production domain should hit the service’s production endpoint right?
d
Dylan Wilder
05/02/2022, 6:51 PMwell what is "execution domain" the domain of the top level workflow?
y
Yee
05/02/2022, 6:51 PM
yeah
(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.)
d
Dylan Wilder
05/02/2022, 6:56 PMconsider 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
but yes i hear you about breaking referential transparency, i think this is an exception
y
Yee
05/02/2022, 11:03 PM
so when would you want flyte to inject what values? what i mean is, you can already configure flyte to add default env vars
but obviously this is static per flyte installation
d
Dylan Wilder
05/02/2022, 11:55 PMLaunch time
y
Yee
05/03/2022, 2:30 AM
why not make it an input?
d
Dylan Wilder
05/03/2022, 12:36 PMcould, but that would result in a spaghetti code wherein every workflow/task needs it
y
Yee
05/03/2022, 4:27 PM
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?
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?
does that make sense? just trying to understand where the source of the information is coming from
g
Gigi
05/11/2022, 8:58 PMWe 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_DOMAINIt seems unwieldy to specify as inputs
For us, we generally can map Flyte domain to our external services env
Thanks for pointing out the default envs per propeller k8s plugin config. We could probably use that, and I was unaware of that feature
y
Yee
05/11/2022, 9:43 PM
created that a couple days ago
mind adding your thoughts on there @Gigi? sorry i should’ve posted it earlier.
can you elaborate what you mean by “per environment” as well?
you mean per flyte domain?
g
Gigi
05/11/2022, 9:53 PMHappy 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_UTLZREST_URL4 Views