Storage Provisioners
Fuzzball V4 uses storage provisioners to manage how volumes are created, accessed, and stored on your cluster. A provisioner is a single entity that combines a storage driver configuration with access policies and optional annotations — replacing the separate storage driver and storage class entities from V3.
V4 storage model:
┌──────────────────────┐
│ StorageProvisioner │
│ · driver config │
│ · access policies │
│ · annotations │
└──────────┬───────────┘
│
┌────────────┼────────────┐
│ │ │
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ volume-1 │ │ volume-2 │ │ volume-3 │
└──────────┘ └──────────┘ └──────────┘
Each provisioner embeds one of Fuzzball’s built-in storage drivers:
| Driver Type | Use Case | Backend |
|---|---|---|
| NFS | On-prem multi-node clusters | NFS export with volume subdirectories |
| Hostpath | Single-node or clustered filesystems (Lustre, GPFS) | Directories under a local path |
| EFS | AWS cloud deployments | Amazon EFS access points |
Fuzzball V4 does not require installing external container-based drivers. All supported storage drivers are built into the Fuzzball platform.
Provisioners are managed at the organization level by organization owners. Group members can create and access volumes based on the provisioner’s access policies.
- Provisioner Definitions — YAML definition format and all configuration fields
- Provisioner Management — CLI commands for adding, listing, editing, scanning, and removing provisioners
- Driver Types — Detailed reference for each built-in storage driver (NFS, Hostpath, EFS)
- Access Policies — Group-based permission model for volume access, creation, and ephemeral usage
- Annotations and Selection — How provisioner annotations work and how Fuzzball selects a provisioner for a volume
If you are upgrading from Fuzzball V3, your existing storage classes are automatically migrated to provisioners during the upgrade. See the V3 to V4 Storage Migration Guide for details on post-upgrade steps.