- a user can publish one checkpoint behind a random v4-UUID code; another
user enters that code in the reinstall dialog and gets a container cloned
copy-on-write from the snapshot (no image is built, so no extra disk until
it diverges), re-provisioned as their own: own IP/ports/disk quota and
network, a fresh hostname/root password/machine-id, the source's
authorized_keys cleared, and no init script run
- publishing deletes the older checkpoints (a clone pins its origin, so they
could never be restored to again); the panel warns with the exact count.
One share per container; deleting the checkpoint/container or reinstalling
revokes it, and a code for the container itself is handled as a restore
- clone via POST /1.0/instances with source.type=copy, then delete the old
container and rename the clone into place; new lx.CloneFromSnapshot /
lx.RenameInstance and a shared instanceSpec() so a clone is configured
exactly like a fresh container
- new snapshot_shares table (schema v14) and /snapshot-share /
/snapshot-unshare panel routes plus the time-machine and reinstall UI
- also fix a refused restore (a checkpoint pinned by a clone) so the
container is always left running, and recognise the "subsequent internal
snapshot(s)" refusal message alongside the existing one
- also give new containers a HARD disk limit: the pool carries
volume.zfs.use_refquota so a volume's usage counts the blocks it
references (including inherited image/snapshot blocks); existing
containers are untouched
Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
