Description
Extract the deploy and destroy orchestration logic from cmd/nic/deploy.go and cmd/nic/destroy.go into a reusable Go package (e.g. pkg/orchestrator) so the CLI becomes a thin wrapper around it and external Go projects can invoke the same flows programmatically without shelling out to the nic binary or duplicating its logic.
The concrete API proposal (package layout, request/result types, option handling) is left to a follow-up ADR.
What moves into the orchestrator
- Config validation (as a safety net — idempotent, cheap).
- Provider lookup and default registry construction.
- Status handler wiring (callers inject the sink).
provider.Deploy invocation.- GitOps bootstrap (
bootstrapGitOps).
- Argo CD + foundational services installation.
- Load balancer endpoint lookup and DNS provisioning.
- Password generation (with an injectable
io.Reader for testability).
- DNS records cleanup (
destroyDNS).
provider.Destroy invocation, including --force handling (continue past provider errors, surface via PartialFailure).
What stays in cmd/nic
- Flag parsing, config file auto-discovery, and
config.ParseConfig call.
- CLI-specific status sink (
statusLogHandler()).
- Pretty-printed instructions (
printArgoCDInstructions, printKeycloakInstructions, printDNSGuidance) — operate on the returned DeployResult.
- Interactive destroy confirmation prompt (
confirmDestruction) — stdin/stdout, not library concern.
- Signal handling / cancellable context.
Use Case
Other Go projects wanting to use nebari-infrastructure-core to deploy a cluster and the foundational software have two options today:
- Embed the
nic binary and shell out to it. This approach means they would need to embed the binary, they would lose typed error handling and they still need to pass a YAML config file on disk.
- Use the different go packages exposed by
nebari-infrastructre-core and duplicate the orchestration logic from deploy.go and destroy.go. This approach would drift over time and would increase the maintenance burden for every provider change or new foundational service.
Refactoring so the CLI is a thin wrapper over a reusable package removes this duplication and makes nebari-infrastructure-core genuinely consumable as a library. It also improves testability of the deploy/destroy flows themselves, since the orchestrator becomes unit-testable without spinning up the CLI.
Description
Extract the deploy and destroy orchestration logic from
cmd/nic/deploy.goandcmd/nic/destroy.gointo a reusable Go package (e.g.pkg/orchestrator) so the CLI becomes a thin wrapper around it and external Go projects can invoke the same flows programmatically without shelling out to thenicbinary or duplicating its logic.The concrete API proposal (package layout, request/result types, option handling) is left to a follow-up ADR.
What moves into the orchestrator
provider.Deployinvocation.bootstrapGitOps).io.Readerfor testability).destroyDNS).provider.Destroyinvocation, including--forcehandling (continue past provider errors, surface viaPartialFailure).What stays in
cmd/nicconfig.ParseConfigcall.statusLogHandler()).printArgoCDInstructions,printKeycloakInstructions,printDNSGuidance) — operate on the returnedDeployResult.confirmDestruction) — stdin/stdout, not library concern.Use Case
Other Go projects wanting to use
nebari-infrastructure-coreto deploy a cluster and the foundational software have two options today:nicbinary and shell out to it. This approach means they would need to embed the binary, they would lose typed error handling and they still need to pass a YAML config file on disk.nebari-infrastructre-coreand duplicate the orchestration logic fromdeploy.goanddestroy.go. This approach would drift over time and would increase the maintenance burden for every provider change or new foundational service.Refactoring so the CLI is a thin wrapper over a reusable package removes this duplication and makes
nebari-infrastructure-coregenuinely consumable as a library. It also improves testability of the deploy/destroy flows themselves, since the orchestrator becomes unit-testable without spinning up the CLI.