Skip to content

pool: a removed pool's golden stays on disk #184

Description

@CMGS

A pool removed through PUT /v1/pools (or dropped from the config file before a restart) leaves its golden behind: SetPools deletes the pool entry (sandboxd/pool/setpools.go), nothing removes <data_dir>/goldens/<hash> and its .cafp/.nic/.warmup sidecars, and Reconcile sweeps only *.tmp staging dirs and stale snapshots (sandboxd/pool/reconcile.go). A golden is a full exported VM (memory image plus disk), so each retired pool or template revision leaves gigabytes on disk until an operator finds them by hand.

The leftover is not useless while the key may come back: adoptGolden re-adopts it on the next PUT of the same key and saves a rebuild, which argues against deleting at removal time.

Fix shape: at startup, after the persisted pools are adopted and their goldens resolved, remove any goldens/<hash> whose hash matches no live pool (nothing can be cloning from it that early), or age them out with a generous grace (days) if a removed key is expected to return. One unit test with a stray golden dir plus the existing TestReconcileSweepsGoldenTmpDirs shape.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions