mirror of
https://github.com/hanzoai/volume.git
synced 2026-10-01 00:48:00 +00:00
zeekay
b61441f7d7
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.
39 lines
924 B
YAML
39 lines
924 B
YAML
apiVersion: apps/v1
|
|
kind: Deployment
|
|
metadata:
|
|
name: hanzo-volume
|
|
namespace: hanzo-volume
|
|
spec:
|
|
replicas: 1
|
|
selector:
|
|
matchLabels:
|
|
app: hanzo-volume
|
|
template:
|
|
metadata:
|
|
labels:
|
|
app: hanzo-volume
|
|
spec:
|
|
serviceAccountName: hanzo-volume-service-account
|
|
containers:
|
|
- name: hanzo-volume
|
|
image: ghcr.io/hanzoai/volume:v0.0.36
|
|
imagePullPolicy: Always
|
|
command:
|
|
- hanzo-volume
|
|
- --debug
|
|
- start
|
|
- --config
|
|
- /etc/config/config.json
|
|
volumeMounts:
|
|
- name: config-volume
|
|
mountPath: /etc/config/
|
|
env:
|
|
- name: POD_NAMESPACE
|
|
valueFrom:
|
|
fieldRef:
|
|
fieldPath: metadata.namespace
|
|
volumes:
|
|
- name: config-volume
|
|
configMap:
|
|
name: hanzo-volume-config
|