Skip to content

Orchestration

The Orchestration tab handles infrastructure-as-template inside the project — Heat-style stacks, autoscaling groups, and software configs. Treat it as the in-Console alternative to Terraform when you want one-shot, all-or-nothing provisioning.

Overview

Orchestration tab Orchestration sub-tabs: Stacks · Autoscaling · Software configs.

Sub-tabs:

Sub-tab What lives here
Stacks Deployments of Heat templates — each stack creates and tracks a set of resources as a unit
Autoscaling Groups Policy- or schedule-driven scaling of VM fleets, integrated with Load Balancer health checks
Software configs First-boot config bundles attached to VMs at create time (cloud-init payloads, scripts, package lists)

Why use Orchestration vs Terraform?

Orchestration (Heat) Terraform
Where it runs In-platform (Heat engine) Outside the platform (your laptop, CI)
State Stored in Cloud Digit Stored in your S3 bucket / Terraform Cloud
Drift detection Built-in via stack update Via terraform plan
Multi-cloud Cloud Digit only Yes
Skill ramp Pre-existing OpenStack Heat / yaml literacy HCL + provider docs
Best for One-shot test environments, simple multi-resource patterns Multi-environment, CI-driven, long-lived infra

For most production estates, Terraform with the Cloud Digit provider is the right call. Orchestration is here for quick experiments and for organizations already comfortable with Heat.

Administration

Quotas

Project Settings → Quota → Orchestration:

  • Stacks per project (default 100)
  • Resources per stack (default 1,000)
  • Autoscaling groups (default 25)

Stack-deployed resources count against their respective service quotas (a stack creating 10 VMs counts those VMs against the project's compute quota).

Defaults

  • Default rollback policy for stacks — rollback on failure (recommended) / keep partial
  • Default autoscale cooldown — 5 minutes (between scaling events)

Operation

Stacks

Creating a stack

Stacks → + Launch Stack:

  1. Name
  2. Template source — paste YAML / JSON, upload a file, or pull from a URL
  3. Environment file (optional) — parameter overrides
  4. Parameters — values for any parameters the template declares
  5. Rollback — on / off
  6. Timeout — minutes before the stack creation gives up
  7. Tags

A stack creates all the resources it declares (or none, if rollback is on and any one fails).

Updating

Stack detail → Update — paste the new template; the engine computes a diff and applies the minimum changes.

Suspending / resuming

Pause and resume a stack — useful when you want to keep the stack definition but stop billing for the underlying resources temporarily. Suspending stops VMs; resuming starts them.

Deleting

Stack detail → Delete — destroys all resources the stack created. Idempotent; safe to retry.

Stack template tips

  • Use conditions to switch between dev/prod patterns from one template
  • Use outputs to surface useful values (LB IP, DB endpoint) to the Console UI
  • Reference Heat documentation for the full template-language spec — Cloud Digit's Heat is upstream-compatible

Autoscaling Groups

Creating

Autoscaling → + New ASG:

  1. Name
  2. Launch template — flavor, image, VPC/subnet, security groups, user-data
  3. Capacity — min / max / desired
  4. Health check — TCP / HTTP / LB target group
  5. Scaling policies — metric-based (CPU / RAM / queue depth via custom metric) / schedule-based (cron) / manual
  6. Cool-down — between scaling events
  7. Lifecycle hooks — pre-terminate, pre-launch (run scripts before the change)

Common scaling patterns

Pattern Setup
Web tier diurnal CPU > 70% scale up, < 30% scale down; cool-down 5 min
Queue worker Custom metric on queue depth; aggressive scale-up, slow scale-down
Schedule-based Cron 0 8 * * 1-5 → desired 10; cron 0 22 * * * → desired 2
Manual via CI Set desired from your CI pipeline at deploy-time

Software configs

A "software config" is a named cloud-init payload (or shell script) you can attach to VMs and stacks. Useful when many resources share the same first-boot setup.

+ New Software Config:

  • Name
  • Format — RAW (cloud-init YAML), Shell (bash), Ansible (playbook)
  • Payload
  • Inputs (optional) — parameters substituted at VM-create time

Reference from a VM create flow or stack template via the config name.

Troubleshooting

Symptom Likely cause Fix
Stack stuck in CREATE_IN_PROGRESS for > 30 min A child resource is stuck (commonly a VM in Building); rollback on Open the stack's Events tab — find the resource holding things up
Stack CREATE_FAILED with no obvious cause Quota exceeded mid-create Check Project Settings → Quota — bump and retry
Update reports replace for resources you wanted in-place Template specifies attributes that aren't update-able for that resource type Refactor template to keep update-able attributes only
ASG scaling triggers fire but desired doesn't change Cool-down still active Check the ASG's scaling history — cool-down period applies after each event
ASG terminates instances unexpectedly Health-check failing — instances marked unhealthy Investigate why instances are failing the health check; check security groups and HTTP path
Software config not applied at boot cloud-init format mismatch (e.g. shell payload labelled as RAW) Confirm the format field; check /var/log/cloud-init.log inside the VM
Stack deletion stuck Child resource has a manual hold (e.g. Object Lock on a bucket the stack created) Resolve the child holds (release retention, etc.); retry stack delete