Problem
Useful infrastructure scripts can still be hard to operate when readiness, approvals, execution history, and handover evidence live in different places. ZTF-Orchestrator explores the control-plane layer around those workflows: the part that helps an operator understand whether a run is prepared, what is queued, what happened, and what evidence exists afterwards.
Components
- Web console: dashboard, workflow launch, YAML Studio, execution history, queues, readiness panels, inventory, and evidence views.
- API layer: constrained routes for workflow execution, validation, runtime checks, artifact generation, and state inspection.
- Workflow boundary: allowlisted ZeroTouch Framework scripts and guided NKP preparation paths rather than arbitrary command execution.
- State layer: local JSON for simple installs, with PostgreSQL available for Docker and appliance-style state.
- Evidence layer: run records, validation output, dashboard signals, release notes, and exported artifacts that make behaviour reviewable.
Trust boundaries
Design requirement: the console, workflow runner, stored state, and target infrastructure should remain separate concerns. The web UI should not become a general shell. Runtime actions are framed around known workflows, explicit inputs, visible readiness, and reviewable results.
Authentication and authorisation
Design requirement: controlled deployments must treat authentication and authorisation as a deployment boundary. Operators should authenticate before using the console, privileged actions should be role-limited, and risky workflows should require an explicit approval path. The public portfolio presents the operating model rather than a production login flow.
Secret handling
Design requirement: secrets belong outside the static site and outside public source. Environment-specific values should be supplied through local configuration, deployment secrets, or host-level environment variables. Implemented: public demos and static screenshots are sanitized so they do not expose live credentials, tokens, or administrative sessions.
Execution flow
- Review runtime and readiness signals before starting work.
- Select a known workflow or preparation path.
- Provide bounded inputs and generate or validate configuration where applicable.
- Queue or run the operation through the orchestrator surface.
- Record the result, failure, or follow-up state for later inspection.
Failure and recovery behaviour
Design requirement: the useful failure mode is not silence. A failed workflow should leave a visible result, enough context to understand where it stopped, and a clear next action for the operator. Recovery should favour re-checking readiness, reviewing generated artifacts, and rerunning bounded workflow steps rather than guessing at partial infrastructure state.
Approval model
Design requirement: the operating model separates preparation from risky action. Approval checkpoints should make destructive or high-impact steps visible before execution. That does not make the project a full enterprise change-management system, but it does show the pattern: planning, readiness, action, result, and evidence should be separate things a reviewer can understand.
Approval states
Implemented: approval states are deliberately simple: pending review, approved for action, rejected or returned for correction, running, completed, and failed. The important point is not the label set itself, but that the operator can distinguish preparation from authorisation, execution, and outcome.
Evidence generation
Evidence is not treated as a screenshot afterthought. The project keeps run history, readiness status, queue state, inventory signals, release notes, and validation outputs close to the workflow surface. This is what makes the project more than a UI concept: it is structured around operational inspection.
Implemented, planned, and excluded capabilities
Dashboard, readiness checks, workflow launch surface, run history, queues, inventory signals, YAML Studio, release notes, approval states, and sanitized evidence snapshots.
Authenticated console access, role-limited privileged actions, externalized secrets, explicit approval checkpoints, and recoverable workflow failures for controlled deployments.
Deeper topology documentation, broader validation examples, richer evidence packaging, and clearer deployment profiles for lab, appliance, and controlled environments.
Vendor support claims, unrestricted shell execution, embedded live secrets, public production control, and any implication that the project is an official Nutanix product.
Limitations
- It is an independent community project, not affiliated with or supported by Nutanix.
- It is designed for lab-facing and controlled use, not presented as a vendor-certified production product.
- Only allowlisted workflows and constrained NKP-safe phases should be treated as in scope.
- Production suitability depends on real environment validation, secret handling, access controls, backup expectations, and operator review.
