Gotchas¶
The host only runs two VMs at once¶
This is the most important operational limit. The executor can wait gracefully, but it cannot create extra host capacity.
Resource overrides happen after create when an image is used¶
This is not a bug in the docs. It reflects the current Jeballto API behavior. If an image is present, resources are patched after creation and before the VM starts.
Password SSH is assumed¶
The executor uses an SSH_ASKPASS flow with the configured password. If your image moves to a different authentication model, the current executor will not use it automatically.
A clean GitLab job failure is different from a host failure¶
- script returns non-zero: build failure
- API timeout, network issue, SSH transport failure: system failure
That distinction affects retries and operator expectations.
File locks are part of normal behavior¶
If you see .lock files under JEBALLTO_STATE_ROOT, that alone is not a problem. They are part of stage serialization and image pull deduplication.
Cleanup is best-effort, but stale local state still matters¶
Even when the Jeballto Agent auto-deletes a VM because it was created as ephemeral, stale local state can still confuse later hook stages. Keep an eye on both sides: the VM list and the state root.