Files
zeekay b61441f7d7 Volume: node-local persistent volumes, under our own name
A fork of Rancher's local-path-provisioner at v0.0.36. The behaviour is
unchanged and deliberately so — a directory on the node a pod lands on is
the right thing for a disk. What changes is identity.

The provisioner answers to hanzo.ai/volume rather than rancher.io/local-path.
That is not branding: two provisioners sharing one name race for the same
claims, and a stock k3s carries the upstream one, so a cluster running both
would settle our storage by chance. Data lives at /var/lib/hanzo/volume, so
reading a Hanzo cluster does not mean learning another vendor's directory.

Apache-2.0 as published, unaltered, with Rancher's attribution in NOTICE.

The README says what this is not: durability. A volume here dies with its
node. That is hanzoai/replicate's question, one layer up, and keeping the
two apart is what lets the disk stay this simple.
2026-09-07 17:30:01 -07:00
..

Overview

this is an example to enable quota for xfs

Usage

  1. build a helper image using the sample dockerfile to replace helper image xxx/storage-xfs-quota:v0.1 at configmap(helperPod.yaml) of debug.yaml.
  2. use the sample setup and teardown scripts contained within the kustomization.
  3. set ALLOW_UNSAFE_HELPER_POD_TEMPLATE=true on the provisioner when using this example, because the helper pod intentionally uses privileged mounts for quota management.

Notice:

  1. make sure the path at nodePathMap is the mountpoint of xfs which enables pquota

debug

> git clone https://github.com/hanzoai/volume.git
> cd local-path-provisioner
> go build
> kubectl apply -k examples/quota
> kubectl delete -n local-path-storage deployment local-path-provisioner
> ALLOW_UNSAFE_HELPER_POD_TEMPLATE=true ./local-path-provisioner --debug start --namespace=local-path-storage