local-path-provisioner
local-path-provisioner copied to clipboard
ZFS example
Hi all :wave:
Just adding a tip in here, in case it saves a couple of minutes for people wanted to use ZFS with this local-path-provisioner. At least it will for me, when i forget it :grimacing:
kind: ConfigMap
apiVersion: v1
metadata:
name: local-path-config
namespace: local-path-storage
data:
config.json: |-
{
"nodePathMap":[
{
"node":"DEFAULT_PATH_FOR_NON_LISTED_NODES",
"paths":["/tank/"]
}
]
}
setup: |-
#!/bin/sh
while getopts "m:s:p:" opt
do
case $opt in
p)
absolutePath=$OPTARG
;;
s)
sizeInBytes=$OPTARG
;;
m)
volMode=$OPTARG
;;
esac
done
#volMode=Filesystem
zfs create -o quota=${sizeInBytes} ${absolutePath:1}
teardown: |-
#!/bin/sh
while getopts "m:s:p:" opt
do
case $opt in
p)
absolutePath=$OPTARG
;;
s)
sizeInBytes=$OPTARG
;;
m)
volMode=$OPTARG
;;
esac
done
zfs destroy ${absolutePath:1}
helperPod.yaml: |-
apiVersion: v1
kind: Pod
metadata:
name: helper-pod
spec:
containers:
- name: helper-pod
image: srueg/zfs-utils
securityContext:
privileged: true
Hm.. ok im sorry. That actually did not work.
When creating or destroying ZFS datasets from a container like the podHelper's one, we need to mount the directory as 'Bidirectional', so the changes can propagate to the Host.
This is maybe related to https://github.com/rancher/local-path-provisioner/issues/165
I guess this can be done enabling the mountPropagation=Bidirectional directly, near here, but that would require the pod helper to run privileged, thus probably would need to be enabled via a flag.
Anyway, another aproach could be something like this?
In case anyone cares, just uploaded a docker image with that change.
With the followin config, ZFS does actually work now =)
kind: ConfigMap
apiVersion: v1
metadata:
name: local-path-config
namespace: local-path-storage
data:
config.json: |-
{
"nodePathMap":[
{
"node":"DEFAULT_PATH_FOR_NON_LISTED_NODES",
"paths":["/tank/"]
}
]
}
setup: |-
#!/bin/sh
while getopts "m:s:p:" opt
do
case $opt in
p)
absolutePath=$OPTARG
;;
s)
sizeInBytes=$OPTARG
;;
m)
volMode=$OPTARG
;;
esac
done
#volMode=Filesystem
zfs create -o quota=${sizeInBytes} ${absolutePath:1}
chmod g+w ${absolutePath}
teardown: |-
#!/bin/sh
while getopts "m:s:p:" opt
do
case $opt in
p)
absolutePath=$OPTARG
;;
s)
sizeInBytes=$OPTARG
;;
m)
volMode=$OPTARG
;;
esac
done
zfs destroy ${absolutePath:1}
helperPod.yaml: |-
apiVersion: v1
kind: Pod
metadata:
name: helper-pod
spec:
containers:
- name: helper-pod
image: srueg/zfs-utils
securityContext:
privileged: true
volumeMounts:
- mountPath: /tank
name: data
mountPropagation: Bidirectional
Thx for the effort, looking forward to trying this out in the coming days :nerd_face:
PR #166 allows to specify the mountPropagation
within the helper Pod template.
What needs to be done in order to integrate this with the volume snapshot API?
I guess this can be done enabling the mountPropagation=Bidirectional directly, near here, but that would require the pod helper to run privileged, thus probably would need to be enabled via a flag.
Anyway, another aproach could be something like this?
In case anyone cares, just uploaded a docker image with that change.
With the followin config, ZFS does actually work now =)
kind: ConfigMap apiVersion: v1 metadata: name: local-path-config namespace: local-path-storage data: config.json: |- { "nodePathMap":[ { "node":"DEFAULT_PATH_FOR_NON_LISTED_NODES", "paths":["/tank/"] } ] } setup: |- #!/bin/sh while getopts "m:s:p:" opt do case $opt in p) absolutePath=$OPTARG ;; s) sizeInBytes=$OPTARG ;; m) volMode=$OPTARG ;; esac done #volMode=Filesystem zfs create -o quota=${sizeInBytes} ${absolutePath:1} chmod g+w ${absolutePath} teardown: |- #!/bin/sh while getopts "m:s:p:" opt do case $opt in p) absolutePath=$OPTARG ;; s) sizeInBytes=$OPTARG ;; m) volMode=$OPTARG ;; esac done zfs destroy ${absolutePath:1} helperPod.yaml: |- apiVersion: v1 kind: Pod metadata: name: helper-pod spec: containers: - name: helper-pod image: srueg/zfs-utils securityContext: privileged: true volumeMounts: - mountPath: /tank name: data mountPropagation: Bidirectional
@killfill I would suggest you can contribute back to the examples
that will be great. Thanks.
Hi @innobead,
Thanks for your comment, but i think for this to work it needs the bidirectional mounting thing enabled. May be a good idea to wait for that first. What do you think?
Hi @innobead,
Thanks for your comment, but i think for this to work it needs the bidirectional mounting thing enabled. May be a good idea to wait for that first. What do you think?
Sounds good to me, let's wait for #165 to resolve first.
@killfill Looks good. Are you ready for submitting a PR for ZFS example?
Hey @derekbit , well I would love to.
But I think some changes needs to be done previously. Im actually using these changes for my little setup, which works, but im not sure its going into the right direction.
All right, adding the example file as a PR. It actually needs the head-master tag, (and probably the next release v0.0.22).
Hope it helps.
@killfill Sorry for the late reply. The PR Looks good. I will test it before merging it. Thank you!