I’m working on migrating from Dagster 0.12.15 to D...
# ask-community
j
I’m working on migrating from Dagster 0.12.15 to Dagster 1.1.13. I’m trying to get it running locally in a docker-compose configuration. I’ve got a pretty similar setup to the example with exception to be explained. When I run
docker-compose up --build
, the dagster daemon fails (nothing else) with the following warning:
Copy code
dagster.daemon.SchedulerDaemon - WARNING - Could not load location dagster_repos:widen_elt_dev to check for schedules due to the following error: dagster._core.errors.DagsterImportError: Encountered ImportError: `No module named 'dagster_repos'` while importing module dagster_repos. Local modules were resolved using the working directory `/opt/dagster/dagster_home`. If another working directory should be used, please explicitly specify the appropriate path using the `-d` or `--working-directory` for CLI based targets or the `working_directory` configuration option for workspace targets.
Exceptions to my setup is that, in my code container, my repo files is found under:
/opt/dagster/app/orchestrate/repo.py
which I’ve countered with a container
command
of :
Copy code
command: ["dagster", "api", "grpc", "-h", "0.0.0.0", "-p", "4000", "-d", "orchestrate", "--python-file", "orchestrate/repos.py"]
and I’ve added the config:
Copy code
- python_package:
      package_name: repos
      attribute: elt_dev
to my
workspace.yml
another error that I’m seeing in the logs is
dagster._core.errors.DagsterUserCodeUnreachableError: Could not reach user code server. gRPC Error code: UNAVAILABLE
I’m not sure which one is causing the other 🤔
I’ve changed the
package_name
config in the
workspace.yml
to just about every variation of
repos
and
orchestrate.repos
that I can think of to no avail. The error will change, reporting whatever I change the value to be. It feels like the working directory suggestion in the error is a red herring since this is running in the daemon, though the error is reminiscent of errors I get when I try to run python code outside of directory where the code is located.
@Joris Ganne my problem looks suspiciously similar to your issue posted here but I don’t see a solution at the end of the thread. Do you remember what you did to solve it?
Update: I figured it out. I actually need to remove the whole
python_package
entry from my
workspace.yml
. When I spin up the docker-compose services I still get an error initially on the daemon with nearly the same error message but I think that’s just because it somehow spins up faster than the grpc server on the code container does. Doesn’t matter though because I can still get to the UI and run everything just fine.
j
@Josh Lloyd I'm sorry for the late answer, but I had a day off yesterday. Nice that you have found the solution!