Volume Configuration and Management
Fuzzball manages storage through two components:
- Storage Provisioner: a named configuration that binds a built-in storage driver to an organization, with access policies controlling which groups can create or use volumes
- Storage Volume: a directory or resource on the storage backend, managed by a provisioner and mounted into workflow containers
Each provisioner embeds one of Fuzzball’s built-in storage drivers:
| Driver | Backend | Typical Deployment |
|---|---|---|
| NFS | NFS export with volume subdirectories | On-prem multi-node clusters |
| Hostpath | Directories under a local or shared filesystem path | Single-node, Lustre, GPFS |
| EFS | Amazon EFS access points | AWS deployments |
Fuzzball V4 does not require installing external container-based drivers. All supported storage drivers are built into the platform. If you are upgrading from V3, see the V3 to V4 Storage Migration Guide for post-upgrade steps.
Provisioners and their policies are managed at the organization level by organization owners. Organization members can create and access storage volumes within their groups based on the provisioner’s access, create, and ephemeral policies.
For detailed information, see:
- Storage Provisioners — provisioner definitions, management, driver types, access policies, and annotations
- Storage Volumes — volume definitions, CLI management, and workflow usage
The V3 storage documentation for Storage Drivers and Storage Classes is retained as reference for V3 deployments. Those pages describe the V3 system and will not work on Fuzzball V4.
Changes to storage provisioners require an authenticated context for an organization owner. Log into an org owner context and confirm that you are an organization owner:
$ fuzzball context login # --direct may work depending on your configuration
$ fuzzball org list-owners # confirm you are a owner