Upgrade from v0.1.x to v0.2.0

This page describes what you must do, beyond the general cross-version upgrade steps, when you upgrade from v0.1.x to v0.2.0. "Step N" on this page refers to the step table in Cross-version upgrades.

v0.2.0 reads only state left by v0.1.x. The check in step 5 lists the following objects as blocking. Handle them as the table describes before you replace the files:

After you move away the record of an ended Instance, starting, stopping, and deleting its Workspace are not affected. The items related to this Instance in the cleanup status show as unknown.

After the upgrade, ctrl has the existing records of ended Instances deleted batch by batch, and kibotos_node_instances{state="stopped"} and {state="destroyed"} go down accordingly. Records with no matching Allocation stay where they are, because ctrl does not recognize them.

When v0.1.x deletes a Volume, it does not end resize, create, or delete commands on it whose result is unknown. Such a command stays processing indefinitely, resending it does not end it, and the target version's check lists it as an unfinished lifecycle operation. After you confirm that the command in the report belongs to a deleted Volume, run the following as ctrl's database account:

UPDATE kibotos_ctrl_commands
SET status = 'completed', error_code = 10, updated_at = now()
WHERE command_id = '<command ID>'
  AND status = 'processing'
  AND volume_id IN (SELECT volume_id FROM kibotos_ctrl_volumes WHERE volume_state = 5);

The command is handled only when the result is UPDATE 1. UPDATE 0 means it is not this kind of command; handle it according to Upgrade check for ctrl. error_code = 10 is aborted, and volume_state = 5 is DELETED, which is the same result the target version produces when it ends such commands while deleting a Volume.

Before you replace the files, also check the configuration and permissions in the following table:

v0.2.0 changes the VMM runtime of the KiboVM backend, and v0.1.x nodes cannot start this version's KiboVM Platform. This is the opposite of "publish the Platform before upgrading the node" in the notes of Cross-version upgrades: after step 7 and before step 8 resumes writes, publish and approve this version's KiboVM Platform. New nodes start VMs only with the new runtime and do not run the old Platform. Running Workspaces are adopted as usual and are not affected.

Workspaces started by v0.1.x keep running their original runtime and Platform until their next start:

• A normal stop proceeds as usual, but the disk is written only to the host page cache, as in v0.1.x. For each such stop, the node logs stop did not confirm the host flush with the reason the VMM's runtime release does not flush on stop.
• On the next start, the Workspace switches to the default of this version's KiboVM Platform. The guest protocol and rootfs contract must be the same. The kernel series may differ.

KiboVM Platforms published by v0.1.x stay in the catalog. If this version does not publish a Platform of the same kernel series, the old default of that series still shows as the default and cannot be withdrawn. Nodes no longer provide the runtime it requires, so neither new Workspaces nor restarted Workspaces select it. No action is needed.

After you upgrade to v0.2.0, you cannot roll back to v0.1.x. A v0.1.x ctrl refuses the migrated database, and a v0.1.x node cannot read the local records and pool metadata written by v0.2.0. Before you replace the files, resolve all blocking items with the check in step 5. If the check fails and the files are not replaced yet, start the original version as usual. See Rollback. Problems that appear after the replacement are fixed on v0.2.x.

Moving pool capacity to ctrlCopy Anchor Link

In the target version, pool capacity is an attribute of the pool on ctrl, and the node configuration no longer declares it. Before you replace the files, remove capacity from every [[storage.pool]] in every node configuration. If the configuration is not changed, check-upgrade in step 5 fails while loading the configuration and suggests using kibo storage-pool set-capacity instead.

kibotos-ctrl migrate in step 6 backfills each pool's capacity from the declarations ctrl recorded before the upgrade. The numbers used for placement do not change:

After the upgrade completes, use kibo storage-pool list to check the CAPACITY of each pool. If it shows - or needs adjusting, set it with kibo storage-pool set-capacity. See Pool capacity.