[POTENTIAL BUG] - Unable to run Quickstart demo

[CjuanRcris7]

Description

I tried to run the quickstart in Ubuntu 24.04, but when doing so, I encountered an error similar to the one reported in issue 26 [BUG - Unable to start the demo], which is currently closed. Looking at the logs, I noticed that from the file conductorScripts/deployments/platform.sh it is attempting to execute a script called /scripts/services/elasticSearchSetup.sh. In the repository, this script is actually named differently due to a capitalization: it is /scripts/services/elasticsearchSetup.sh, so the file is never found.

Even after fixing this (I renamed the script to match, so it became /scripts/services/elasticSearchSetup.sh), the make platform command still produces errors when starting the containers due to an issue with the "Maestro" service:
ERROR | org.springframework.boot.SpringApplication | Application run failed.

The error seems related to Linux cgroups and a Java NullPointerException:

Thanks for taking a look at this!

[MitchellShiell]

Hey! Thanks for reaching out, I suspect this is a docker version issue

If you pull the most recent commit you'll see the updated casing fix (good catch), i've also added a pre-deployment check script that you can run with:

make deployCheck

You'll get some basic feedback on whether you are set up for success (docker version + resources available)

Let me know how it goes, if pre-deployment is successful and the problem persists I can test further in Ubuntu 24.04 to see if i can replicate

Thanks again for reaching out
Mitchell

[CjuanRcris7]

Hi, Mitchell:
Thanks for your help!

I ran the deployCheck script and it completed successfully, although it displayed a warning about the number of CPU cores. I’m not sure if this is a critical issue that could affect the deployment.

Since I don’t have Docker Desktop installed, I assume this CPU core limitation shouldn’t apply in my case — is that correct?

I’ve attached a screenshot of the deployCheck output, in case it helps identify whether my system might still be missing some of the recommended requirements, even though the check shows a successful result.

Regarding the first message related on the elasticsearchSetup.sh script, thank you — it’s now fixed and working properly.

However, even though the deployCheck script completes successfully, I’m still getting the same error as before when running the application: ERROR | org.springframework.boot.SpringApplication | Application run failed.

Thanks again for your support,
Juancris

[MitchellShiell]

Great, ok been poking around and i think i've identified the issue, working on updating the maestro image now, that should fix it.

If interested i do have a more lightweight demo branch available: https://github.com/overture-stack/prelude/tree/demo/exploration

I'll update here once i make the commit

[MitchellShiell]

K, I've updated the branch to use our newer version of maestro, it's written in typescript so will resolve the compatibility issue with JAVA.

Thanks for catching this, i'm seeing a few other things i'd like to update here, i'll spend some time next week updating the quickstart and the relevant guides, in the meantime i'll point you to the simpler/newer demo branch .

I'll also extend an invite to schedule a chat, always happy to hear how people are thinking about using our software and helping them get started. If interested shoot me an email at contact@overture.bio and we can arrange a zoom call.

Of course let me know if this resolves your issue, Cheers!

[CjuanRcris7]

Hi, Mitchell:

The quickstart branch is working perfectly now, thank you very much!
I also tried testing the demo branch, but I ran into a couple of issues, which I’m sharing here in case it helps.

First, I got a "Bad substitution" error. The Makefile uses parameter expansion like ${variable:0:64}, which only works in bash, but make was using /bin/sh by default. I tried adding SHELL := /bin/bash as the first line of the Makefile, and that seemed to work!

Then I hit an "exec format error" during the Docker build. The docker-compose.yml had platform: linux/arm64/v8 for the stage service but linux/amd64 for everything else. Since I'm on x86_64, I changed stage to linux/amd64 to match, and that solved it.

After these changes, everything works perfectly!
Thanks again for your help!