Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ZFS example #162

Closed
killfill opened this issue Dec 16, 2020 · 14 comments
Closed

ZFS example #162

killfill opened this issue Dec 16, 2020 · 14 comments

Comments

@killfill
Copy link

Hi all 👋

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 😬

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
@killfill
Copy link
Author

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 #165

@killfill
Copy link
Author

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

@markusressel
Copy link

markusressel commented Dec 29, 2020

Thx for the effort, looking forward to trying this out in the coming days 🤓

@mgoltzsche
Copy link
Contributor

PR #166 allows to specify the mountPropagation within the helper Pod template.

@haslersn
Copy link

What needs to be done in order to integrate this with the volume snapshot API?

@innobead
Copy link
Collaborator

innobead commented Mar 2, 2021

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.

@killfill
Copy link
Author

killfill commented Mar 2, 2021

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?

@innobead
Copy link
Collaborator

innobead commented Mar 2, 2021

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.

@derekbit
Copy link
Member

@killfill
Looks good. Are you ready for submitting a PR for ZFS example?

@killfill
Copy link
Author

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.

@killfill
Copy link
Author

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.

@derekbit
Copy link
Member

@killfill
Sorry for the late reply. The PR Looks good. I will test it before merging it. Thank you!

Copy link

github-actions bot commented Aug 2, 2024

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

@github-actions github-actions bot added the stale label Aug 2, 2024
Copy link

github-actions bot commented Aug 8, 2024

This issue was closed because it has been stalled for 5 days with no activity.

@github-actions github-actions bot closed this as completed Aug 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants