Knowledge Base

Service Lifecycle — Provision, Suspend, Cancel, Reactivate

Provisioning

When a service activates, the module creates (on the storage server): the client's storage user (shared across their services), a per-service access key pair, the bucket (bucket-<clientID>-<serviceID>), the package quota, the visibility policy and the per-service IAM policy.

Important: when adding a service manually, add it as Pending and then Activate it — never directly as Active. The bucket name is derived from the service ID, which doesn't exist yet when a service is created directly as Active; the module blocks that attempt with a clear error.

Suspend / Unsuspend

Suspension is per-bucket: a deny-all policy is placed on that one bucket. The client's storage user is never disabled, so their other services keep working. Unsuspension restores the package's normal public/private policy.

Cancellation → staged cleanup

Cancelling a service never deletes the bucket inline (a huge bucket can take hours to remove). Instead the bucket is queued in the Bucket Cleanup plugin and deleted through its staged, approval-gated flow — see the Bucket Cleanup Plugin article. If the cleanup plugin is not installed, cancellation is blocked.

Reactivation after cancellation

If an admin reactivates a cancelled service, the cleanup plugin handles it automatically on its next hourly run:

  • Bucket still exists (cleanup still in progress): the cleanup is aborted — the expiration rule is removed, the bucket policy is restored, and the queue record is marked Aborted. Files already expired by the 24-hour rule are not recoverable.
  • Bucket already deleted: the bucket is re-provisioned automatically — recreated empty with the package quota and visibility. The client's user, access keys and IAM policy survived, so their credentials keep working.

Neither the cron nor the admin "Delete Now" button will ever delete a bucket whose service is active again.

Admin service tabs

On a service's admin page, the Advanced Features tab upgrades a legacy bucket (provisioned before module 2.3.0) so the client gets versioning/lifecycle self-service — it re-applies the current user policy and stamps the service. One click, POST-confirmed.

Please rate this article to help us improve our Knowledge Base.

0 0