https://flyte.org logo
Join Slack
Powered by
making this a top level thread for visibility :sli...
# flytekit
d
making 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
where would they come from?
d
you 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
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
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
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
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
well what is "execution domain" the domain of the top level workflow?
y
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
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
but yes i hear you about breaking referential transparency, i think this is an exception
y
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
Launch time
y
why not make it an input?
d
could, but that would result in a spaghetti code wherein every workflow/task needs it
y
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
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.
It 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
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
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
164 Views
Open in Slack
PreviousNext
Powered by