Relationship between config in the launchpad vs. config in code

[yuhan]

Lately, it comes up pretty often that the relationship between config in the launchpad vs. config in code is unclear. A few instances:

• https://dagster.slack.com/archives/C01U954MEER/p1652267056104319 — config value filled by .configured doesn’t show up anywhere
• Improve "View Configuration" & "Open in Launchpad" actions for Schedules #7814 — for schedules, no way to view the config im about to run before actually running the job
• https://dagster.slack.com/archives/C01U954MEER/p1652355319482489

So, I'm opening this discussion for collecting user scenarios and feedback, e.g. how your mental model is about this relationship, how you expect the config view/edit experience to be in Dagit.

[PascalStehling]

As described here (#7880), the default values that are defiend in code should be shown in the OP View in the Launchpad. This makes it easier to understand certain OPs.

[cbini]

Reiterating a couple points for Schedules:

1. Under Runs > Scheduled, when you click either "View Configuration" or "Open in Launchpad", you should see the final config that should run, including all merged config and tags from the Job defaults.
2. Under Workspace > Schedules, when you click into a Schedule instance, you should be able to preview the launch configuration. Perhaps with diff formatting for config and tags of where it differs from the Job defaults
3. When you click into a Run of a Schedule, the schedule name should be prominent somewhere. Currently, it's buried in the "View tags and config" modal

[samuelstuetz]

While a launchpad and code config should obviously match I think the bigger issues is that resources using configured in code do not show the config with which they where run.
To reiterate it is not that there is inconsistency it is that the actual configuration of e.g. a materialized run is not logged or viewable anywhere. It either works or doesn't but the code does not communicate it.

1. Under runs the View tags and config has to show the run configuration meaning that if a resource_xy.configured(...some_config...) exists in code this config must be there or alternatively there must be a different way to configure the resources. Otherwise debugging materialize runs becomes 🤷.

Quite simply

query RunsQuery {
  runsOrError {
    ... on Runs {
      results{
    	runConfig
      }
    }
  }
}

should never return empty {} for runs if there clearly is configured resources. E.g. I have failing runs because of misconfiguration and the config is empty.

I think this should be quick first.

[CezaryPukownik]

The things I wish could be set by Launchpad are:

• Resource configuration and op if not dynamic.
• Configuration of schedules ex. cron strings.

Additionally, the ability for Launchpad to save configs globally for DAGSTER_HOME would be very useful. Currently they seem to be saved in the browser cache and can be lost.

I don't know how this could be done through API changes, but maybe adding "parameters" that can be defined by dagit.

from dagster import DagitConfigurable

@schedule(
    job=my_job, 
    cron_schedule=DagitConfigurable(config_key='cron_schedule')  # this is refering to Status/Schedules/Schedule column in Dagit.
)
def my_job(context):    
    return RunRequest(
        run_key=None,
        run_config=context.launchpad_config['default'], # this is refering to launchpad tab-name.
    )

[samuelstuetz]

user story / use case
As a orchestration(dagster) user I may have some runs which where executed some weeks ago (long time to emphasise). The code repository has been deployed multiple times since then (with significant code changes to the job in question). Now I want to understand why my new code isn't running as well as it used to. Therefore I want to see any and all configuration that is relevant to the run which executed successful 3 weeks ago.

Needed workarounds at the moment:

• roll back the code repository and search for the code which ran, check the config that was executed by merging it with the run_config logged in the run log >^ quite inconvenient and slow
• (I use at the moment) log the actual config for each resource on init out as debug. >^ inconsistent and also generic logging may be a security problem, potentially logging passwords or keys

What would be a really good long term solution.
config_version_log -> anytime a job executes log the config used to a separate table (if deduplication is useful) or just directly to the job. Allow config fields of type SecureString & SecureStringSource (-> secure should be sanitised in logs and also not stored in the db store *** instead)
standard log information should be visible for historic runs regardless if configured in code or launchpad or sensor.
as far as secure config fields go that with a logger helper function that makes sure people can easily display config information even if it comes from the environment without leaking secure information would be a neat benefit.

[geoHeil]

Great points above. Furthermore, there should be a scaffold defaults button to scaffold the configuration including the default values.

As default values are a means of communication towards less technical users (they can tinker around and set different ones easily but might not know how to structure them in the configuration) it would be really beneficial if dagster supported this behavior.