Closed miabbott closed 3 weeks ago
There's nothing you can do to speed this up other than maybe having a faster network connection. It needs the current metadata in order to correctly depsolve the blueprint so if you are starting osbuild-composer and immediately starting a build you just have to wait.
osbuild-composer does do a pre-load of the supported distros when it starts up though, so if you have an instance that is left running instead of starting it on demand it will seem faster the next time you start a build.
The reason why the cli waits is because the server runs a depsolve first, it is useful to know 'immediately' if the start command you just issued really started or if it failed because of a problem with the blueprint.
Describe the bug
When starting a compose that targets a specific distro, there is significant lag between the use of
composer-cli compose start
and the command returning, due toosbuild-composer
preloading all of the supported repos. The time elapsed is around 3 minutes.Environment
/etc/os-release
and/etc/redhat-release
):rpm -qi osbuild-composer)
To Reproduce
subscription-manager
osbuild
bitsrhel-94
edge-commit
composecomposer-cli compose start
and the command returningExpected behavior
The
composer-cli compose start
command should return quickly since only a single distro is being specified in the blueprint. Additionally, the CLI is just POST'ing to the API, so it should be able to fire and forget?Additional context
Upon further investigation of the logs, it looks like
osbuild-composer
started the "preload goroutines" before the compose was started. It looks like this may have been a case of bad timing. But given that there is no output provided on the CLI aftercomposer-cli compose start
, it can be confusing to the user what is actually going on.Relevant logs showing when the preload started, when the POST happened for a new compose, and when the next POST for the queue happened.