Hi All 🙂 I've just upgraded from 0.9.9 to 0.10.0 -- i think i've caught most of the breaking changes, but I am now encountering an error with my pipelines that are loaded from gRPC:

hi kevin - is your grpc server using the same instance config that dagit is using? it looks like the run storage is different for some reason on the gRPC server.

it should be; the grpc image is built from the same image as the dagit image -- it just has the .py files that include the pipelines

got it - what are you using for your run storage?

telemetry:   enabled: false                run_storage:   module: dagster_postgres.run_storage   class: PostgresRunStorage   #  config:   #  postgres_db:   #    username:   #      env: DAGSTER_PG_USERNAME   #    password:   #      env: DAGSTER_PG_PASSWORD   #    hostname:   #      env: DAGSTER_PG_HOST   #    db_name:   #      env: DAGSTER_PG_DB   #    port: 5432 event_log_storage:   module: dagster_postgres.event_log   class: PostgresEventLogStorage   #config:   #  postgres_db:   #    username:   #      env: DAGSTER_PG_USERNAME   #    password:   #      env: DAGSTER_PG_PASSWORD   #    hostname:   #      env: DAGSTER_PG_HOST   #    db_name:   #      env: DAGSTER_PG_DB   #    port: 5432 scheduler:   module: dagster_cron.cron_scheduler   class: SystemCronScheduler schedule_storage:   module: dagster_postgres.schedule_storage   class: PostgresScheduleStorage   #config:   #  postgres_db:   #    username:   #      env: DAGSTER_PG_USERNAME   #    password:   #      env: DAGSTER_PG_PASSWORD   #    hostname:   #      env: DAGSTER_PG_HOST   #    db_name:   #      env: DAGSTER_PG_DB   #    port: 5432   #compute_logs:   #module: dagster_aws.s3.compute_log_manager   #class: S3ComputeLogManager   #config:   #  bucket: "mycorp-dagster-compute-logs"   #  prefix: "dagster-test-" # ================================================================================================== # Run Launcher # ================================================================================================== # Component that determines where runs are executed. #run_launcher: #  module: dagster_k8s.launcher #  class: CeleryK8sRunLauncher local_artifact_storage:   module: dagster.core.storage.root   class: LocalArtifactStorage   config:     base_dir: "/opt/dagster/local/" # ================================================================================================== # Execution # ================================================================================================== # Defining the execution to use celery-k8s #execution: #  celery-k8s: #    config: #      job_image: 'genimind/dagster-core:v0.0.2' #      job_namespace: 'dagster'

do those comments indicate that the run storage doesn't have any config?

it's quite possible i'm returning to Dagster after what feels like a 6 month hiatus, so teach me sensei

So I was under the impression that you needed to have some kind of config on postgres storage for it to work - but if you're able to use that instance in dagit I may be wrong?

exactly

what i'd expect if you use an instance with no config is that you'd see an error like this when you start dagit: "Error 1: Must specify a field at the root if more than one field is defined. Defined fields: ['postgres_db', 'postgres_url']"

this is the other place i would think i would have defined it

that looks right - so if you go into dagit you should be able to click on Instance Details - that should show you the YAML that dagit at least is using

run_storage: module: dagster.core.storage.runs class: SqliteRunStorage config: base_dir: /tmp/tmpa48gq0s6/history/

i think our best bet is to get it using the postgres rather than finding a way to get the gRPC to reach sqlite

ENV DAGSTER_HOME=/opt/dagster/dagster_home

are these yaml files based on our helm chart? If so I can see how this is supposed to work there

it should be -- when updating to 0.10.0, i copied over the new helm chart from your repo

got it - so your dagit deployment should have something like this then?

volumeMounts:
            - name: dagster-instance
              mountPath: "{{ .Values.dagsterHome }}/dagster.yaml"
              subPath: dagster.yaml

yeah so using the helm chart this is the values.yaml file we pass to it

got it - to confirm, you're running into this issue when using the standard helm chart? With the only thing modified is the values.yaml?

yes that and the instance-config which i previously sent

i think for dagit you should be able to use the default repository/tag that comes in the helm chart (since your user code is in a different container anyway) - maybe try using the default value for that instead of repo/dagster-core , and see if your instance is configured correctly using postgres now?

okay i'll give that a whirl and let you know!

You should build user code ideally with the same dagster version as whatever the dagit image you’re using is, in this case with 0.10.0 versions of all libraries

yeah i made sure of that, with my own images -- but if i'm already using 0.10.0 versions of the libraries would it make any difference to base it off of your default 0.10.0 dagit image?

I don't think basing it on the dagit image would make a difference - mostly just trying to isolate differences to figure out why the instance doesn't seem to be loading. Once we get dagit working we can hopefully get to the bottom of why its not loading in your gRPC server