Dylan Wilder

    Dylan Wilder

    4 months ago
    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?
    Yee

    Yee

    4 months ago
    where would they come from?
    Dylan Wilder

    Dylan Wilder

    4 months ago
    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
    Yee

    Yee

    4 months ago
    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.
    Dylan Wilder

    Dylan Wilder

    4 months ago
    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
    Yee

    Yee

    4 months ago
    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?
    Dylan Wilder

    Dylan Wilder

    4 months ago
    well what is "execution domain" the domain of the top level workflow?
    Yee

    Yee

    4 months ago
    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.)
    Dylan Wilder

    Dylan Wilder

    4 months ago
    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
    Yee

    Yee

    4 months ago
    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
    Dylan Wilder

    Dylan Wilder

    4 months ago
    Launch time
    Yee

    Yee

    4 months ago
    why not make it an input?
    Dylan Wilder

    Dylan Wilder

    4 months ago
    could, but that would result in a spaghetti code wherein every workflow/task needs it
    Yee

    Yee

    4 months ago
    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

    4 months ago
    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
    Yee

    Yee

    4 months ago
    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

    4 months ago
    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