Tags: turbot/steampipe
Tags
Bump Go to 1.26.5, security-flagged dependencies, and FDW to 2.2.5 fo… …r v2.4.5 (#5023) - go.mod and workflow go-version pins: Go 1.26.1 -> 1.26.5 (Go stdlib CVEs incl CVE-2026-27143) - golang.org/x/crypto 0.47.0 -> 0.52.0 (CVE-2026-39830..39834, CVE-2026-42508, CVE-2026-46595) - github.com/containerd/containerd 1.7.29 -> 1.7.33 (CVE-2026-46680, CVE-2026-53488) - github.com/go-git/go-git/v5 5.17.1 -> 5.19.1 (CVE-2026-45022, CVE-2026-41506) - github.com/go-git/go-billy/v5 5.8.0 -> 5.9.0 (CVE-2026-44973) - oras.land/oras-go/v2 2.5.0 -> 2.6.2 (CVE-2026-50151) - github.com/hashicorp/go-getter 1.7.9 -> 1.8.6 (CVE-2026-4660) - FdwVersion 2.2.4 -> 2.2.5 - CHANGELOG entry for v2.4.5
Add INFO-level progress logging to the cross-major migration engine A 14->18 migration on a large data tank can run for over an hour, but the engine only logged at TRACE (off by default) and WARN, so an operator saw almost nothing between `service start` and the final status file. Add INFO lines at each engine milestone (start, dump, restore-complete-at-tier, validate, commit) and at each restore tier (reserved-word route, tier 1 parallel, tier 2 serial escalation, tier 3 per-table COPY, tier 4 per-partition COPY), with per-table progress in the COPY tiers and a periodic per-partition counter for tables of 500+ partitions. Logging only; no behaviour change.
Working dumps never outlive a cross-major attempt; old data is the so… …le failure-recovery copy Design decision (2026-06-11): the dump is the restore SOURCE, not a retained artefact. Tier 1's parallel pg_restore requires an on-disk directory-format dump, so the dump must exist during the attempt - but retaining it afterwards bought nothing real: on failure the untouched old data directory is the recovery copy (every retry re-dumps from it), and after commit rollback belongs to the platform's backup story (pgbackrest in Pipes - in a pod the dump was container-ephemeral anyway, so 'retained' was already fiction there). Meanwhile a parked failed workspace held gigabytes of dead dump on a possibly shared volume. - deleteMigrationDumps removes backup.bk, public.dump and the data-tank dump dir; called at commit AND in failCrossMajor before fail-stopping. The engine itself never deletes (lifecycle belongs to the caller), so the engine-level preservation tests are unchanged and still assert the dump survives a failed run. - crossMajorMigrationFailedError drops the retained-dump parameter; manual recovery now points at the preserved old directory (a complete cluster, startable/dumpable with the matching binaries). - The data-tank status JSON keeps retained_dump_path (schema-compatible) documented as in-window only. - Same-major (minor) migration retains its historical ~/.steampipe/backups behaviour, untouched. - The disk pre-flight's 2x-data-size budget already envelopes the dump's transient footprint. Test: TestDeleteMigrationDumps (all three artifacts removed; no-op safe when absent).
Bump pipe-fittings to v2.9.1 to fix GHCR plugin install auth error (#… …4982) pipe-fittings v2.9.1 adds an anonymous retry to OCI pulls when stored GHCR credentials (from ~/.docker/config.json) are rejected. Without this, an expired or revoked PAT causes 'steampipe plugin install' to fail with an opaque 403 even when the image is publicly pullable. Also updates cloud.bats acceptance test fixtures (AWS account 632902152528 / alias 'nagraj-aaa' → 097350876455 / 'turbot-silverwater') to match the current turbot-ops/clitesting workspace state.
PreviousNext