Provisioning overview

Provisioning is the first of ZopDay’s three stages (provision, deploy, operate): it stands up the network, the cluster, and the datastores under your services, on your own AWS, GCP, or Azure account. Every infrastructure change runs through one job state machine, so clusters, VMs, and datastores retry, resume, and report the same way on all three clouds.

Infrastructure → Provision: one drawer for every resource type (clusters, VMs, databases, and caches).

Before you start

• A cloud account connected with the provisioning permissions for what you want to create. See Cloud permissions.
• The provisioning:create policy (and provisioning:view to follow jobs). See RBAC.
• A region, a name, a size, and a networking decision: a new VPC or an existing one.

How it works

What the provisioner creates

Two more things are created alongside them rather than as jobs of their own:

• Networking (VPC, subnets, NAT, security groups) is chosen with the drawer’s Network option (create a new VPC or use an existing one) and applies to cluster, VM, and datastore jobs. For clusters and VMs, it runs as a step inside the job. See Networking.
• In-cluster Helm components install onto a cluster after its provisioning job completes, each as its own logged, retryable action. See Components.

Four job kinds, one state machine

Because all four run on one state machine, the reconciler, retries, and the job timeline behave the same way for each. Changes to a resource that already exists, such as resizing a VM in place, run as update jobs on the same state machine. Clusters, datastores, and VMs all use them. See Resizing a VM in place.

Job lifecycle

pending → running → completed
             ↓
           failed → retry (resumes from the last successful step)

Each step inside the job is idempotent. If a pod restarts mid-step, the reconciler picks up where it left off and re-runs the step. The repeated cloud API call either fails fast on “already exists” or does nothing. The reconciler holds a row-level lock with a TTL that exceeds the worst-case step duration.

Modes

Retrying is not a separate mode: a retry resumes a failed job of either mode from the last successful step. For Adopt jobs, teardown is a no-op: ZopDay never owns the lifecycle of adopted resources. Disconnecting an adopted resource only removes ZopDay’s pointer to it. The underlying datastore keeps running.

Pipeline steps

Each family has its own pipeline, but they share a structure. For clusters:

Validate → Create network → Create IAM → Create cluster
        → Register space → Finalize

For VMs, always 10 steps:

create_network → create_iam → LB security group → VM security group
            → create VM → wait for ready → bootstrap
            → create load balancer → attach VMs to LB → register_space

The load balancer is mandatory because it is the public route to the VMs, so there is no shorter variant without one. The network, IAM, and space-registration steps are shared across families, so clusters and VMs create them the same way. Default Helm components are not a step in the cluster pipeline; they install after the job completes. Datastore jobs follow the same shape; see Datastores.

Customer DB safety

After a datastore is created, ZopDay never changes its tier, replica count, or backup policy on its own, even when ZopDay created it. No schedule, recommendation, or remediation does it, and managed databases are not on the provisioner’s pause list. ZopDay acts on a database only when you ask: an update job you start, a teardown of a datastore ZopDay created, or a Cloud SQL copy (which overwrites an existing MySQL target database only if you choose that). See Datastores.

To get sizing recommendations for a DB without anything changing it, attach it to a ZopNight event readiness plan as a monitor-only target. ZopNight computes the recommendation, and you make the change through your normal DB workflow.

Start a provisioning job

1. Open the Provision drawer

   Go to Infrastructure and click Provision.

2. Pick what to provision

   Choose Kubernetes Cluster, Virtual Machine, MySQL Database, PostgreSQL Database, or Redis Cache.

3. Fill in the form

   Pick the cloud account and region, set the name and size, and choose the network (Create new VPC or Use existing VPC). Advanced settings holds further options, with defaults already applied.

4. Provision

   Click Provision. The job runs in the background.

Follow and retry a job

Follow the job in Activity → Provisioning Jobs, which counts jobs by state: running, pending, completed, and failed. A failed job shows the failing step and its error. Fix the cause and retry; the job resumes from the last successful step (POST /provisioning-jobs/{jobID}/retry).

Reference

State carried in the job config

The provisioner carries each resource family’s state across steps in the job’s config JSON. For VMs that means VMs[], VMSecurityGroupID, LoadBalancerID, ScalingGroupID, LaunchTemplateID, ExistingResourceGroup, BootstrapNginxReady, and so on. A new resource type adds fields to the job config instead of needing a schema change.

Endpoints

Jobs:

POST   /provisioning-jobs              Create
GET    /provisioning-jobs              List with filters
GET    /provisioning-jobs/{id}         Get one
PATCH  /provisioning-jobs/{id}         Partial update (also used for VM op discriminator)
DELETE /provisioning-jobs/{id}         Cancel + cleanup
POST   /provisioning-jobs/{jobID}/retry   Retry from last failed step

Job-scoped databases:

GET    /provisioning-jobs/{jobID}/databases
POST   /provisioning-jobs/{jobID}/databases
GET    /provisioning-jobs/{jobID}/databases/{dbID}
DELETE /provisioning-jobs/{jobID}/databases/{dbID}

Datastore connections:

GET    /provisioning-jobs/{jobID}/connections
GET    /provisioning-jobs/{jobID}/connections/{connID}
POST   /provisioning-jobs/{jobID}/connections
DELETE /provisioning-jobs/{jobID}/connections/{connID}

GET    /provisioning-jobs/{jobID}/databases/{dbID}/connections
GET    /provisioning-jobs/{jobID}/databases/{dbID}/connections/{connID}
POST   /provisioning-jobs/{jobID}/databases/{dbID}/connections
DELETE /provisioning-jobs/{jobID}/databases/{dbID}/connections/{connID}

Helm component catalogue:

GET    /orgs/{orgID}/components                        List available Helm components
POST   /orgs/{orgID}/components/{component}/upgrade    Upgrade an installed component to a new chart version

On clusters that ZopDay provisions, the components you pick install once the provisioning job completes, and the default baseline (ingress, TLS, and metrics) installs before the first service deploy if anything is missing. Each install runs as its own logged, retryable action, not as a provisioning job. See Components.

VM operations after provisioning use the existing PATCH route with a typed vmOp discriminator, which keeps the API small:

PATCH /provisioning-jobs/{id}
{
  "vmOp": "attach_lb"     // or "detach_lb"
}

RBAC

Viewing the audit log is governed by its own audit-log:view policy. System roles (Admin, Editor, Viewer) inherit these policies. Custom roles need explicit grants.

Troubleshooting

Next steps