Skip to content

Provider-target authority migration Phase Two #1100

@cbusillo

Description

@cbusillo

Intent

Migrate Launchplane from Dokploy target/id records as implicit target identity authority to explicit provider-target records as the stable target identity boundary.

Current Status

Phase Two initial data authority setup is complete through the deployed service/workflow path. Evidence:

  • Add provider target operations workflow #1111 merged and deployed the provider-target operations service route/workflow.
  • Improve provider target workflow reruns #1112 merged and deployed workflow rerun/concurrency hardening.
  • Provider Target Operations final audit run 26827648062 returned complete:1 for discord-blue/prod, verireel/testing, verireel/prod, cm/testing, cm/prod, opw/testing, and opw/prod.
  • Service health after deploy was OK on Postgres, trace launchplane_req_5e307808247b4046979fc17a26efa187.

Next action: #1104 is now unblocked and active. Cut over live target identity reads to provider-target authority while keeping Dokploy records as provider execution config until #1106 retirement.

Finish Line

Launchplane writes explicit provider-target rows on target identity mutations, backfills existing live lanes, uses provider-target records as live identity authority for deploy/promotion/read workflows, validates VeriReel/SYO/Odoo/generic-web evidence, and retires compatibility aliases/fallbacks only after production evidence is clean.

Sequencing

  1. Provider-target parity audit and drift report #1101 Provider-target parity audit and drift report. Done in Add provider-target parity audit #1107.
  2. Dual-write provider-target rows on target identity mutations #1102 Dual-write provider-target rows on target identity mutations.
  3. Backfill explicit provider-target rows from Dokploy records #1103 Backfill explicit provider-target rows from Dokploy records.
  4. Cut over live target identity reads to provider-target resolver #1104 Cut over live target identity reads to provider-target resolver.
  5. Validate provider-target authority product-by-product #1105 Validate provider-target authority product-by-product.
  6. Retire provider-target compatibility aliases and projection fallback #1106 Retire provider-target compatibility aliases and projection fallback.

Safety Gates

  • Audit must report zero unresolved mismatches before backfill apply or authority cutover.
  • Backfill must be dry-run first, idempotent, and fail closed on partial/conflicting records.
  • Dual-write errors must surface; no silent fallback.
  • Provider-target identity must agree with Dokploy execution metadata before any Dokploy adapter action.
  • Odoo and VeriReel prod cutovers happen only after lower-risk lanes produce clean deploy/promotion/health evidence.

Live Production Risks

  • VeriReel depends on Dokploy route metadata for base URLs and health checks, so identity cutover must preserve provider-specific execution reads.
  • SYO can expose product-profile/lane drift and target category/name defaults.
  • Odoo is highest risk because compose targets, post-deploy, overrides, backup gates, runtime identity, target replacement, and rollback all depend on exact target identity.
  • generic-web is shared blast radius; resolver tests must cover base-driver inheritance and route-scoped compatibility.
  • Existing stale explicit provider-target rows already take precedence, so audit/backfill must block conflicts before cutover.

Explicit Non-Goals

  • Do not add new non-Dokploy providers in this phase.
  • Do not move release ownership back to product, tenant, shared-addon, or local-DX repos.
  • Do not make ProviderTargetRecord absorb Dokploy route/runtime execution config yet.
  • Do not remove Dokploy execution adapters or Dokploy execution records.
  • Do not use broad feature flags; use audits, explicit data evidence, PR sequencing, and fail-closed validation.

Metadata

Metadata

Assignees

No one assigned

    Labels

    planDurable planning issueplan:activeCurrent active plan

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions