In a docker deployment using separate user code containers, what does the "reload location" button at the lower-left of the dagit UI actually do? Does it restart the user code container?

It does not restart the user code container - it reloads dagit's copy of the data (which often isn't very useful since its unlikely to have changed unless the user code container has restarted)

Thanks, Daniel. Is there any way to have this type of deployment detect changes to the user code so that it can be refreshed in the UI without a

docker-compose down

and

docker-compose up

?

there isn't currently a way to do it without restarting the code server in some way - but this comes up frequently and we're looking into ways to support this better

Thanks! FWIW, the documentation is misleading in this regard, I think.

I would definitely believe that - is there a specific page or paragraph you're thinking of?

I think some of it has to do with legacy discussions of using @repository vs. the module structure. It's also b/c of the "reload location" buttons on the dagit UI. I've set up containerized modules as code locations, based on following the documentation, so I expected "reload location" to detect that those changed. Now that I know that it doesn't, I can move on to other work instead of trying to debug my setup. 🙂 This page is pretty clear that the user code container needs to be rebuilt and restarted if code is updated, though: https://docs.dagster.io/deployment/guides/docker#multi-container-docker-deployment For now, I'll probably just modify my CI pipeline to restart the relevant container(s). A more specific paragraph outlining recommended way to handle reloading user code containers would be nice to have in the docker deployment section of the documentation. It's somewhat of a must-have feature for setups with multiple people managing work on dagster.

I think a possible end state here would be dagster more directly managing the user code containers instead of relying on docker compose to do it - e.g. the daemon could spin up a container for each code location on startup, and when you hit reload it could deploy a new one for you

That would be good. Our environment is very cloistered, so I have to rely entirely on internal tools for my work. We have an internal gitlab instance that we can use for CI. My use case involves 2-3 teams who will each maintain a repository of user code (1 per team, initially - more later, perhaps) for dagster. In a perfect world, they would have dev/prod branches in their git repo and when they pushed to a prod branch, the CI system could deploy the code to the dagster server and dagster/daemon/dagit would notice the change and optionally prompt the user to reload the code location through the UI. (Optionally, it could automatically reload.) For now, I'll write a bash script that the CI can execute that will pull the git repos to the server and then restart the user code containers