Overview
Polystack Orchestration is built on a three-tier architecture: an API tier that accepts template submissions, an engine tier that resolves dependencies and drives resource provisioning, and a plugin layer that delegates individual resource operations to the appropriate cloud service API. The engine is stateless — all stack state is persisted in a relational database, enabling horizontal engine scaling.Service Topology
Service Components
The Orchestration API and CloudWatch-compatible API are separate processes. Both must
be running for auto-scaling and
WaitCondition resources to function correctly.
Port 8000 must be accessible from instances that use WaitCondition signal URLs.How the Engine Processes a Template
Request Flow Details
Template Parsing
The engine parses the YAML template and evaluates allparameters sections, applying
default values where the caller did not provide overrides. Intrinsic functions are
not evaluated at parse time — they are resolved lazily when a resource is being
provisioned and its dependencies are known.
Dependency Graph Resolution
The engine constructs a directed acyclic graph (DAG) from:- Explicit
depends_ondeclarations in resource definitions - Implicit dependencies detected from
get_resourceandget_attrreferences in resource properties
CREATE_COMPLETE.
Resource Plugin Architecture
Each resource type (Polystack::Compute::Server, Polystack::Networking::Net, etc.) is
handled by a dedicated plugin that implements a standard interface:
Database Schema Overview
The Orchestration service persists all state in a dedicated database schema:Next Steps
Configuration
Configure the Orchestration service, quotas, and stack domain
Scaling the Service
Deploy multiple engine workers for high-throughput deployments
Security
Stack domain users, trust authorization, and policy configuration
Admin Troubleshooting
Diagnose engine failures and service-level issues
