-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
opam.ocaml.org takes a too long and unpredictible time to deploy #92
Comments
opam2web does not take very long to build the tool, but it does take a long time to run once it has been built. Typically, the overall run is 90 minutes. As you note, there is some unpredictability in pushing to Docker hub: the process can timeout or just randomly fail as the layers are very large. The machines opam-4.ocaml.org and opam-5.ocaml.org run Docker in swarm mode. We use However, we don't need to push to Docker hub, just a Docker registry. We could build opam.ocaml.org on a specific machine with a Docker registry running locally. Running a Docker registry seems straightforward, and adding authentication isn't too hard. The push would then be local, not over the network. The update step on opam-4 and opam-5 would then pull from this registry rather than Docker hub. This removes the push over the network and should guarantee the performance of the push. I have created a PR#211 to do this and tested it using a cluster worker with a large local disk (x86-bm-c9.sw.ocaml.org). @avsm @dra27 |
Thank you so much @mtelvers! ❤️ |
This pipeline has now been deployed for a couple of weeks and seems to be giving us a consistent deployment time |
Thank you so much! ❤️ |
opam2web only takes 30mins to build. However, ocurrent-deployer (for some ungodly reason) wants to push the resulting 22GB image to docker hub, just to pull it again right after. This whole process in the end takes 3+ hours, sometimes more if docker hub doesn’t like it, and somtimes even twice that when opam-repository maintainers merge PRs in the middle.
Could we please detach this whole "wait for docker hub twice" process and simply transfer the docker image to the target server directly?
The text was updated successfully, but these errors were encountered: