b-f-chan
commented
3 years ago Tested on Mac with these specs:
- MacOS Catalina 10.15.7
- 3.1 GHz Quad-Core Intel Core i7
- 16 GB RAM 2133 MHz LPDDR3
- More than 20 GB disk space available
- Also, Docker adjusted to use 4 CPUs and 8 GB RAM as resources
Summary:
- Deployed successfully, all services successful except DMS-UI, which field to start service (Docker replica 0/1)
- Other services started and reachable (UIs, APIs)
- @blabadi will check & test tagged version of DMS-UI to see if any issues
Specific Issues:
- As mentioned, DMS-UI not starting
- Additionally, the logo asset directory is not being set correctly, it is still prefixed with
/home/ubuntu, but should instead detect and use the Mac home directory
dmsUI:
hostPort: 8000
url: "http://localhost:80/dms-ui"
adminEmail: "bfcwork2018@gmail.com"
ssoProviders: "GOOGLE,GITHUB,LINKEDIN,ORCID"
labName: "Ogre Genomics"
logoFileName: "dms_logo.jpg"
assetsDir: "/home/ubuntu/.dms/assets"Timing results
Due to this new change, images are pulled at the beginning of the dms cluster startcommand, before any services are actually deployed:
- Pulling all images took 7 min 3 sec (423 sec)
- After pulling images, deployment itself took additional 1 min 4 sec (64 sec)
- Total time in this environment: 8 min 7 sec (487 sec)
Additional feedback:
- Suggest adding some non-transient status messages that shows updates as each image is pulled and completed (e.g. arranger-ui image downloaded, ego-ui image downloaded, etc.)
- Currently, messages are shown but it is only on one line that gets overwritten constantly, so it flickers too quickly for users to see what's going on
- Users may not necessarily care about each individual image, but the status messages will give them a feel that things are progressing, after all it took 7 minutes and can seem a long time to users
While testing with Mac, it was found that the current process for downloading the images for all the Overture services is not ideal, often taking too long and causing timeouts depending on the user's system resources, internet connection etc.
Currently, only the DMS image is pulled at the start of the script. All the individual service images are downloaded on the fly as the deployment process starts. If the user's bandwidth or connection speed is low, the process can timeout because some images are very large. Additionally, some services are dependent on others being deployed first, so if an image is not downloaded yet, this further extends deploy time. The timeout and retry value in the config.yaml can be adjusted, but this is still not a sure way to guarantee all the images are downloaded.
For example, on MacOS with 4 CPU cores and 12 GB RAM, on 40 Mbps download connection speed, the large images took as follows:
Download speed was noticeably faster testing on a Dell Linux machine with 300 Mbps download connection, but not all users will have access to such a fast connection.
Proposed Solution: Solution proposed is to change the download trigger points. Instead, download all the images at the start of the script, either before or as part of the configuration steps, so that they are ready BEFORE deploy even starts and do not risk deployment failure.