https://dagster.io/ logo
#ask-community
Title
# ask-community
m

Mykola Palamarchuk

01/10/2023, 3:18 PM
Hi! Is there a way to provide
run_config
for
build_asset_reconciliation_sensor()
somehow?
s

sandy

01/10/2023, 5:30 PM
Hi Mykola - can you explain your use case a little more? Why are you using config in this situation?
m

Mykola Palamarchuk

01/11/2023, 12:18 PM
I have some resources used by assets. So to materialize them I need the resources to be configured. They are configured pretty well in case of materialization by a
job
but there is no place to configure them in case of reconciliation sensor. Or did I miss something?
(some assets use their own config definition as well)
s

sandy

01/11/2023, 4:05 PM
Got it - our recommended way of configuring resources in this situation is with
configured
. For example:
Copy code
defs = Definitions(assets=..., resources={"my_resource_key": my_resource.configured(...)})
More detail here: https://docs.dagster.io/concepts/configuration/configured#using-configured
(some assets use their own config definition as well)
We've had some recent discussion about how to handle this situation. Why use config for these assets vs. just hardcode the behavior inside the function body? Do you sometimes kick off ad-hoc runs with different config? Do you store your config in YAML?
m

Mykola Palamarchuk

01/12/2023, 8:28 AM
@sandy, our use is mostly related to sensitive parameters (e.g. db connection credentials). For the moment we use env variables passed as StringSource fields in config (as this was a recommended way). About hardcoding the behavior: that may work for our own resource definitions, but standard Dagster resources (like "s3_resource") should not be changed probably.
configured
is an option here. Will it work for assets as well?
s

sandy

01/12/2023, 9:31 PM
configured
works for resources, but not for assets. when I asked if you could just hardcode the behavior inside the function body, I only meant to suggest that for assets, not for resources
3 Views