In a docker deployment using separate user code co...
# ask-community
c
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?
🤖 1
d
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)
❤️ 1
c
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
?
d
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
❤️ 2
c
Thanks! FWIW, the documentation is misleading in this regard, I think.
d
I would definitely believe that - is there a specific page or paragraph you're thinking of?
c
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.
d
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
c
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
Thanks for the information! 🙂
127 Views