How bucket provisioning works

End-to-end flow from a WHMCS order to a live bucket — what the module does, what audit log entries to look for at each step, and where to dig if a provisioning task stalls.

Last updated 20 days ago

How bucket provisioning works

When a customer orders an ImpulseDrive plan, ImpulseMinio walks a fixed sequence to turn that order into a live bucket with credentials. Knowing the sequence saves debugging time when something fails partway.

The flow

  1. WHMCS order lands. Standard WHMCS provisioning fires the module's CreateAccount server-module function. The order carries the product, the customer, and any configurable options (region selection, in the multi-region case).

  2. Server selection. ImpulseMinio's load balancer picks a destination server. Pinned plans go to one of the listed servers; Auto plans go to the default server for the region, then any server in the region with capacity, then a cross-region fallback. If no server has capacity, the order is held and the audit log writes a provisioning_held event.

  3. Tenant + bucket creation. The module hits the destination MinIO host's admin proxy on TCP 9099. The admin proxy calls the MinIO admin API to create the per-tenant user, create the bucket, and apply setBucketQuota from the plan's Storage MB. A row is written to mod_impulseminio_tenants linking the WHMCS service id to the MinIO user / bucket.

  4. Access keys. An initial S3 access key is generated and stored. Customers create additional keys themselves from the client area.

  5. Credentials surfaced. The S3 endpoint, region slug, access key, and secret are written to the WHMCS service custom fields and rendered in the customer area on the ImpulseDrive tab. The standard WHMCS welcome email is sent if you configured one.

  6. Lifecycle hooks armed. Subsequent SuspendAccount, UnsuspendAccount, and TerminateAccount calls now flow through the same admin proxy to disable, re-enable, or delete the tenant.

The whole flow typically completes in under 10 seconds for an existing server. The first provision on a freshly-provisioned VPS waits on the bootstrap cron — see Adding a server for that path.

What the audit log writes

Every step writes to Core's audit log scoped to module impulseminio and the WHMCS service id. Successful provisions look like:

order_received → service 1234 / plan starter / region us-central-dallas server_selected → server 7 (us-central-dallas-1) tenant_created → user u_1234 / bucket b_1234 / quota 50000 MB access_key_issued → key AKIA... credentials_published → service custom fields written welcome_email_sent

Failures stop at the step that failed and log the upstream error verbatim — provider API response, MinIO admin API response, or admin proxy error.

Where to look when something fails

Three sources, in this order:

  1. Core's audit log. Filter by module impulseminio and the affected service id. The last successful row tells you how far the flow got; the next (failed) row tells you why it stopped.

  2. Core's cron log. If the failure is in a polling-style task (waiting on bootstrap, waiting on DNS) the cron log shows each tick and the exact error each time. Check mod_impulsecore_cron_log.

  3. The destination server's bootstrap log. Only relevant for failures during VPS bootstrap (i.e. provisioning the server, not the tenant). The Servers tab shows a View Log button that fetches the bootstrap log over SSH from the box.

Common stall points

  • Admin proxy unreachable from WHMCS. Firewall on the destination server, or admin-proxy Bearer token mismatch. The audit log writes proxy_health_failed with the exact HTTP status.

  • MinIO admin API rejects the create. Usually the MinIO root credentials configured for the server have rotated. Re-enter them on the server row in the Servers tab.

  • DNS not propagated yet (new-server case). The first tenant on a brand-new server can race the Let's Encrypt cert issuance. The provisioning task retries on the next cron tick.

  • Plan has server restrictions and no server matches. Configuration mistake on the plan. The audit log writes no_eligible_server with the plan id and the configured restrictions.

If a tenant ends up half-created (MinIO user exists but the WHMCS side never recorded it), use the Customers tab's Re-sync from MinIO action to reconcile. It walks the MinIO admin API, finds the orphan, and either adopts it into the WHMCS service or deletes it depending on what you choose.

Related