• Onebox v32.7.0
    Release / build-and-release (push) Successful in 20m47s
    Stable

    jkunz released this 2026-09-24 19:02:32 +00:00 | 24 commits to main since this release

    2026-09-24 - 32.7.0

    Features

    • Move Corestore's data out of Docker's own data root. The engine conversion wrote Corestore's data root into its stage volume, and the first maintenance container that named that volume made Docker create it as a plain local volume under /var/lib/docker/volumes; every later mount asked for a volume bound to an Onebox directory, which Docker ignores for an existing volume, so Cloudly's database and the fleet's image registry lived where removing Docker deletes them. onebox migration corestore-data --approve --checkpoint-reference <reference> moves the root into the Onebox-owned volume corestore, bound to the directory the Corestore platform storage class names for it (/var/lib/onebox/corestore by default), where a fresh install keeps it. It renames the root inside its filesystem and refuses to copy it, because NoSQLDB fences its storage root by path and inode and Corestore binds its restore claims to device and inode; a staged volume on another filesystem is refused by name before anything moves. The command admits a completed conversion with every Onebox service and consuming platform service stopped, records the running owner's readiness, resource inventory and the content digest of every database, keeps the stopped owner as onebox-migration-corestore-data-recovery-<relocation-id>, proves with an inventory of every entry's inode, links, owner, mode, size and modification time that the renamed root is the same, starts a candidate with the same image and authority on the explicitly created volume, and names it in the conversion journal only after it served the same inventory and digests. Every step is journaled in the record corestore-data-relocation and resumes with the same command; Onebox refuses to start in between. --rollback returns the root, the owner and the prior target until --complete --external-acceptance-reference <reference> accepts the move, and --status prints the value-free record without initializing Onebox. The conversion journal records a committed relocation as dataRelocation, which Onebox releases before this one refuse; a completed target replacement waits until the relocation is accepted and then runs on corestore.

    Fixes

    • Create every platform data volume explicitly and refuse one whose storage differs. A platform container named its data volume with the storage class's driver options, and Docker silently used an existing volume of that name with whatever options it had, so a volume Docker had created on its own kept its data inside Docker's data root while Onebox's configuration named a bound Onebox directory. OneboxDockerManager.ensurePlatformDataVolume now creates the volume with its resolved driver, options and labels, or proves that the existing one has exactly that driver and those options, before createPlatformContainer creates a container; a differing volume is refused by name and no container is created on it. On a host converted before this release, Corestore's configured volume is the conversion stage volume Docker created on its own, so the Corestore provider cannot recreate onebox-corestore until onebox migration corestore-data has moved its data; the refusal names that command for a plain stage volume.
    • Stop letting a maintenance container create volumes. runMaintenanceContainer refuses a bind that names a volume Docker does not know, and one that is no volume name, before it pulls or creates anything. The Corestore engine conversion creates its stage and export volumes explicitly through the Corestore platform storage class before their first use, so a new conversion keeps both in Onebox directories from the start, and its export evidence is read from the bound directory rather than from Docker's mountpoint, which is empty while no container uses the volume.
    • Let the Corestore database content digest name a platform consumer's database. CorestoreProvider.getDatabaseContentDigest accepted only onebox-service-<id> and refused the onebox-platform-<type> service ids under which Corestore keeps the databases of Onebox platform services such as CoreMail.
    Downloads