Hey guys, where/how does exactly the partition_fn ...
# deployment-kubernetes
r
Hey guys, where/how does exactly the partition_fn gets run? I have defined a partition_fn that queries my database and returns a list of company names to be used as Partitions and when running this locally my partition set is properly generated and I am able to run backfills. However, when I deploy to k8s and attempt to run a backfill I get the following error (which is somewhat generic):
Copy code
AttributeError: 'ExternalPartitionExecutionErrorData' object has no attribute 'partition_names'
  File "/usr/local/lib/python3.7/site-packages/dagster_graphql/implementation/utils.py", line 14, in _fn
    return fn(*args, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/dagster_graphql/implementation/fetch_partition_sets.py", line 221, in get_partition_set_partition_statuses
    for partition_name in result.partition_names
I have installed the helm chart using a custom service account binded to a Workload Identity that has access to my database, so I should be able to query the database from anywhere (dagster daemon, dagit, run jobs, etc.). I believe this has nothing to do with permissions, but may have something to do with the ENV variables defined in a configmap that are only mapped to my user deployment (hence the question about where it is being run)
d
Hi Ruben - partition_fn will execute in your user code deployment (the same place dagit loads your pipeline code from). It looks like you're running into a place where we're not handling errors correctly (cc @prha re: backfill callsite), or we'd be able to see what exactly the error is
r
Yeah, I got the same error locally when I was wrongly generating the list of partitions, but managed to fix it so that it worked locally. I'm sure this is a different error now but I can't tell
d
I'll file an issue for the error handling piece
r
Thanks Daniel
Although I cannot tell due to the generic error, I believe my issue is related to this https://github.com/dagster-io/dagster/issues/3934 since my dagster-user-deployments sub chart is not inheriting the serviceAccount from the helm chart and is instead using the default one
dagster-release-dagster-user-deployments-user-deployments
r
the issue should be resolved - you can set
global.serviceAccountName
in the parent chart to ensure that the subchart references the service account that you want
r
Yeah, you are right Rex, we hadn't upgraded to 0.11.2 so we didnt use this yet. Thanks!