feat(plugins): canary tier filter for /admin/plugin-updates/:id/apply #115

New Issue

claude-ceo-assistant · 2026-05-08T14:52:59Z

2026-05-08 14:52:59 +00:00

Problem

Plugin updates today fan out as the operator runs install commands per-workspace. When a queued update from #4 is approved (#2), we need a structured rollout: canary tier first, soak time, then production tier — not a 'paste this curl loop and YOLO' shape.

Proposed approach

POST /admin/plugin-updates/:id/apply (from #4) accepts a tier filter:

tier: "canary" — applies to workspaces tagged canary in the workspaces table (a new update_tier column added in the same migration as #4).
tier: "production" — applies to all production-tagged workspaces.
tier: "all" — applies to everything (for emergency fixes only).

Default workspace tier on creation: production (so existing customers default-safe). Synthetic staging workspaces get canary tier explicitly.

Operator workflow:

Queue update lands (#4 detects upstream drift)
Operator reviews the queued update
Operator: POST /admin/plugin-updates/:id/apply -d '{"tier":"canary"}'
Soak — operator monitors canary tenant(s) for N hours / one task cycle
Operator: POST /admin/plugin-updates/:id/apply -d '{"tier":"production"}'
Apply automatically uses #3 hot-reload + #5 atomic install

Acceptance criteria

Migration adds update_tier column to workspaces (default "production")
/admin/plugin-updates/:id/apply accepts tier field; rejects invalid values
Tier=canary affects only canary-tagged workspaces
Tier=production excludes canary-tagged
Tier=all logs a loud warning + requires force: true
Idempotent — re-applying canary after canary is no-op (already at target version)
Tests: tier filter applies correctly; force-required for all

Out of scope

Multi-canary tiers (canary-A, canary-B) — single tier is sufficient for a 1-customer deployment
Automated soak detection (operator decides when to promote)
Per-region rollout — irrelevant at current scale

Refs

internal#TBD — plugin-update-policy.md (the human procedure this codifies)
molecule-core#TBD — version subscription (#4) — feeds queued updates
molecule-core#TBD — atomic install (#5) — applies safely
molecule-core#TBD — hot-reload classifier (#3) — applies fast where possible

## Problem Plugin updates today fan out as the operator runs install commands per-workspace. When a queued update from #4 is approved (#2), we need a structured rollout: canary tier first, soak time, then production tier — not a 'paste this curl loop and YOLO' shape. ## Proposed approach `POST /admin/plugin-updates/:id/apply` (from #4) accepts a tier filter: - `tier: "canary"` — applies to workspaces tagged `canary` in the workspaces table (a new `update_tier` column added in the same migration as #4). - `tier: "production"` — applies to all production-tagged workspaces. - `tier: "all"` — applies to everything (for emergency fixes only). Default workspace tier on creation: `production` (so existing customers default-safe). Synthetic staging workspaces get `canary` tier explicitly. Operator workflow: 1. Queue update lands (#4 detects upstream drift) 2. Operator reviews the queued update 3. Operator: `POST /admin/plugin-updates/:id/apply -d '{"tier":"canary"}'` 4. Soak — operator monitors canary tenant(s) for N hours / one task cycle 5. Operator: `POST /admin/plugin-updates/:id/apply -d '{"tier":"production"}'` 6. Apply automatically uses #3 hot-reload + #5 atomic install ## Acceptance criteria - Migration adds `update_tier` column to `workspaces` (default `"production"`) - `/admin/plugin-updates/:id/apply` accepts `tier` field; rejects invalid values - Tier=canary affects only canary-tagged workspaces - Tier=production excludes canary-tagged - Tier=all logs a loud warning + requires `force: true` - Idempotent — re-applying canary after canary is no-op (already at target version) - Tests: tier filter applies correctly; force-required for `all` ## Out of scope - Multi-canary tiers (canary-A, canary-B) — single tier is sufficient for a 1-customer deployment - Automated soak detection (operator decides when to promote) - Per-region rollout — irrelevant at current scale ## Refs - internal#TBD — plugin-update-policy.md (the human procedure this codifies) - molecule-core#TBD — version subscription (#4) — feeds queued updates - molecule-core#TBD — atomic install (#5) — applies safely - molecule-core#TBD — hot-reload classifier (#3) — applies fast where possible

claude-ceo-assistant closed this issue

2026-05-08 15:55:50 +00:00

Sign in to join this conversation.