Skip to content

refactor(power-orchestrator): move to tools/ + drive build/deploy via Fallout (#191) - #232

Merged
ChrisonSimtian merged 1 commit into
mainfrom
refactor/power-orchestrator-to-tools-fallout
Jun 30, 2026
Merged

refactor(power-orchestrator): move to tools/ + drive build/deploy via Fallout (#191)#232
ChrisonSimtian merged 1 commit into
mainfrom
refactor/power-orchestrator-to-tools-fallout

Conversation

@ChrisonSimtian

Copy link
Copy Markdown
Collaborator

Why

PowerOrchestrator lived under stacks/ but was never a converge-able stack (no stack.yaml). It's a .NET service deployed as a systemd unit on the nuc-01 node — not a Proxmox guest — so the engine's converge can never provision it. It also shipped a hand-cranked install.sh that sat outside the repo's Fallout build entirely.

This addresses both: (1) wrong home, (2) off-pipeline installer.

What

  • git mv stacks/PowerOrchestrator → tools/PowerOrchestrator — history-preserving. New tools/ seam; clean for the eventual subrepo extraction.

  • Fallout owns build/test/publish (native dotnet) via new targets in build/Build.cs:

    Target Does
    CompilePowerOrchestrator dotnet build the solution
    TestPowerOrchestrator + xUnit suite — what CI runs
    PublishPowerOrchestrator + self-contained linux-x64 single-file → publish/
    DeployPowerOrchestrator publish, then shell out to deploy/deploy.sh
  • install.shdeploy.sh — stripped of dotnet publish (Fallout does that now); pure copy-onto-node + systemd "deploy sugar" the Deploy target invokes. Refuses to run without a Fallout-produced publish/ rather than building.

  • CI: .github/workflows/power-orchestrator-ci.yml runs ./build.sh TestPowerOrchestrator on PRs touching the tool (mirrors validate-shapes feed setup).

  • Path-reference fixes (README, .service comment, monitoring otel-collector comment, build/README target table). .fallout/build.schema.json regenerated with the 4 new targets.

Why a build target, not a converge stack

The engine only converges Proxmox guests (LXC/VM) and UniFi networks. PowerOrchestrator is a systemd unit running on the host — no guest to converge — so a dedicated build target is the right fit, not new engine surgery. Documented in build/Build.cs + build/README.md.

Verification

Run locally through Fallout:

  • ./build.sh TestPowerOrchestrator → compile + 19/19 tests pass
  • ./build.sh PublishPowerOrchestrator → 110 MB self-contained binary in publish/ (gitignored)

No build artifacts staged; no lingering stacks/PowerOrchestrator references.

🤖 Generated with Claude Code

… Fallout (#191)

PowerOrchestrator lived under stacks/ but was never a converge-able stack (no
stack.yaml) — it's a .NET service deployed as a systemd unit ON nuc-01, not a
Proxmox guest. And it shipped a hand-cranked install.sh outside the repo's
Fallout build.

- git mv stacks/PowerOrchestrator → tools/PowerOrchestrator (new tools/ seam,
  clean for the eventual subrepo extraction).
- Add Fallout targets in build/Build.cs: CompilePowerOrchestrator →
  TestPowerOrchestrator (what CI runs) → PublishPowerOrchestrator →
  DeployPowerOrchestrator. Fallout owns build/test/publish (native dotnet).
- install.sh → deploy.sh: stripped of dotnet publish (Fallout does it); now
  pure "copy onto node + systemd" sugar that the Deploy target shells out to.
  Refuses to run without a Fallout-produced publish/ rather than building.
- CI: .github/workflows/power-orchestrator-ci.yml runs ./build.sh
  TestPowerOrchestrator on PRs touching the tool (mirrors validate-shapes feeds).
- Fix path references (README, .service comment, monitoring otel-collector
  comment, build/README target table). .fallout/build.schema.json regenerated
  with the 4 new targets.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@ChrisonSimtian
ChrisonSimtian merged commit a4a251b into main Jun 30, 2026
6 checks passed
@ChrisonSimtian
ChrisonSimtian deleted the refactor/power-orchestrator-to-tools-fallout branch June 30, 2026 11:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant