vwiebe/conductor
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity
conductor/SLICE13.md

7.7 KiB
Raw Blame History

SLICE13 — Idempotent Conductor upgrade process

Status: Complete — implementation and local acceptance

Purpose

Provide one reusable upgrade process that preserves customer data, configuration and installed applications and can be rerun safely.

Working instructions

Read CODEX.md and applicable AGENTS.md instructions before work. Current source and tests are authoritative. Preserve unrelated working-tree changes. Use this file as both the slice specification and its continuing log.

This slice is separate from SLICE10; the user authorized implementation on 2026-09-14. Update the checklist and append dated log entries as work proceeds. Record decisions, changed files, checks and results, failures, unresolved issues and the next action. Do not erase earlier log entries or claim VM/release acceptance from local tests alone.

Scope

  • Choose a shared upgrade implementation exposed through an upgrade mode or update-conductor.sh; avoid accumulating one-off numbered patch scripts.
  • Inspect current installation and target compatibility before changing live state; support a read-only dry run.
  • Back up Conductor data, keys, configuration and installed-app state before mutation.
  • Preserve users, passwords/keys, projects, publications, app packages, registry records and API connection settings.
  • Apply supported migrations once and keep source-independent installed apps functional during core upgrades.
  • Use locking and repeatable steps so interrupted or repeated runs do not duplicate apps, regenerate credentials or reset settings.
  • Check health and representative application routes after upgrade.
  • Provide and verify recovery to the previous working image/data combination.
  • Document update, retry, compatibility-failure and recovery procedures.

Acceptance checks

Action Purpose / expected behavior
Upgrade the existing supported installation Customer data, identity and installed applications remain available.
Repeat the same upgrade No duplicate entries, unnecessary key rotation or configuration reset occurs.
Interrupt a controlled test upgrade and rerun The process resumes safely or exits with an actionable recovery path.
Simulate failed health/compatibility checks Live state is preserved or the documented recovery path restores service.
Run dry-run with protected setup records sudo permits inspection while no application state changes.

Boundaries and dependencies

Depends on SLICE12. Preserve the earlier completed slices and their logs.

The customer control panel and other SaaS backlog items remain outside these four slices. The user reports only one live Conductor instance, which has Social Scheduler installed. A clean Conductor reset is an available fallback if a safe retrofit is impractical; first record the exact scope and backup/recovery plan. This does not authorize wiping the entire VM or deleting Node-RED's saved connections or PostgreSQL's schedules.

Progress log

2026-09-13 — Plan recorded

  • Renamed the proposed four phases to SLICE10, SLICE11, SLICE12 and SLICE13, respectively.
  • Implementation has not started.

2026-09-14 — Implementation and acceptance in progress

  • User authorized SLICE13. Preserved the SLICE12 work and unrelated scripts-repository changes; starting files are backed up under the sibling .local/conductor-slice13-start directory.
  • Implemented a reusable update-conductor.sh with protected dry-run, compatibility checks, maintenance locking, an interruption journal, consistent full-volume/image/configuration snapshots, offline candidate checks, promotion to a copied data volume, automatic recovery and explicit archived-image/data rollback.
  • Added an app-owned legacy connection recipe in social-scheduler/integration/conductor-migration.json. The local upgrade bundle includes only the verified Social Scheduler 0.5.0 browser package; it migrates an already registered 0.4.0 app and does not seed an absent app.
  • Added the upgrade/recovery guide and disposable Ubuntu/nested-Docker/browser tests. The old image fixture is rebuilt from the original Social Scheduler 0.4.0 archive.
  • Initial browser test needed correction: Playwright's Node-side API client did not use Chromium's test-host DNS mapping. Authenticated fixture calls now run inside the browser, through the generated HTTPS route.
  • Initial checks pass: legacy account/project/publication and Social Scheduler rendering, protected dry-run, corrupt-package/incompatible-image refusal, actual SIGKILL recovery and failed-candidate health recovery. Remaining acceptance is in progress.
  • No customer VM, live social account, Node-RED flow or PostgreSQL database has been changed.

2026-09-14 — Final acceptance and local delivery

  • Final isolated acceptance passed using the current kit: protected read-only dry-run; bad image/package refusal; actual SIGKILL and rerun recovery; failed-candidate health and automatic recovery; the original 0.4.0 combined frontend migrated to a persistent 0.5.0 package; unchanged existing database rows and decryptable secrets; same administrator password; preserved saved project and publication; existing account/queued-post view through the authenticated API; application title/default favicon; repeat no-op; and a second independent app surviving another core image.
  • Routine backup/restore passed with the shared maintenance lock, including restore's nested safety backup. Corrupt upgrade archives were rejected before live changes. Explicit rollback passed after the old image and original volume were removed and with the active service stopped. The saved image was reloaded and its corresponding data restored; repeating the rollback was a no-op.
  • The published standalone Conductor v1.0.0 image also upgraded to v1.1.0, with no Social Scheduler or other app falsely added. The same upgrade command then returned already-current.
  • The backend API fixture's container identity/start time, account/queued-post state and zero-write counter were unchanged. Caddy stayed byte-identical. The isolated VM had no Node.js installed. This checks the Conductor/API boundary with a read-only fixture, not a real Bluesky post or an actual Node-RED/PostgreSQL migration.
  • Browser screenshots were reviewed. Shell and embedded-Python syntax, documentation links (65 Markdown files), governance and whitespace checks passed. The initial test-browser DNS issue was resolved and the final run was clean.
  • Main deliverables: sibling skeletonworks-scripts/update-conductor.sh; matching maintenance-lock changes in backup/restore scripts; setup's existing-installation pointers; docs/CONDUCTOR_UPGRADE.md; reproducible fixture, bundle and acceptance scripts; and the app-owned social-scheduler/integration/conductor-migration.json recipe.
  • Local release/conductor-upgrade-1.1.0.tar.gz includes the tested updater, fresh setup, backup/restore scripts, upgrade guide, checked Social Scheduler browser assets and per-file checksums. The Conductor image and published Social Scheduler 0.5.0 archive were not changed.
  • Evidence: test-results/slice13/result.json, browser JSON/logs and screenshots, plus test-results/slice13-final.log. Disposable test hosts and their nested data were removed. No customer VM or live social account was accessed.
  • All SLICE12/SLICE13 installer and documentation changes remain local and uncommitted/unpushed. Existing unrelated working-tree edits were preserved.

Current handoff

SLICE13 implementation and local acceptance are complete. Transfer the local upgrade bundle and checksum file to the customer VM, follow its INSTALL.md dry-run/update steps, and perform the read-only customer checks in the guide. Real customer-VM acceptance and publication of these installer changes have not been performed.