Skip to content

add additional directory for driver to mount on the host #387

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.

Sign up for GitHub

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

Closed
jsloyer wants to merge 1 commit into from
Closed

add additional directory for driver to mount on the host #387

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions deploy/kubernetes/releases/csi-digitalocean-dev/driver.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -405,6 +405,11 @@ spec:
# needed so that any mounts setup inside this container are
# propagated back to the host machine.
mountPropagation: "Bidirectional"
- name: kubelet-data-dir
mountPath: /var/data/kubelet
Copy link
Contributor

@timoreimann timoreimann Aug 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this to support a kubelet root directory alternative to the default /var/lib/kubelet (i.e., your deployment of kubelet diverges from the default)?

Copy link
Author

@jsloyer jsloyer Aug 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@timoreimann yeah if that’s ok.

Copy link
Contributor

@timoreimann timoreimann Aug 23, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can totally see how you (and others) may want to use a non-standard directory. What I'm not too sure about is whether adding additional mount points is the right way to achieve that. At the least, it could be surprising/confusing to users to see several mounts where only one is effectively used.

My suggestion would be to keep the manifests as-is and adjust your local copy to your needs. It's also possible to use one of the many manifest management tools out there to keep upstream (i.e., our manifests) unchanged and put customizations on top in a maintainable fashion. Examples are kustomize, kpt, and ytt.

Let me know if that works for you.

Copy link

@sandaymin123 sandaymin123 Aug 24, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current changes should work out-of-the box across all environments and configs. If we want something easy
without adding additional work on the end-user.

name: plugin-dir
              mountPath: /csi
            - name: pods-mount-dir
              mountPath: /var/lib/kubelet
              # needed so that any mounts setup inside this container are
              # propagated back to the host machine.
              mountPropagation: "Bidirectional"
            - name: kubelet-data-dir
              mountPath: /var/data/kubelet
              # needed so that any mounts setup inside this container are
              # propagated back to the host machine.
              mountPropagation: "Bidirectional"
            - name: device-dir
              mountPath: /dev

If we want something where the user must override then we must have a supported deployment mechanism that can be templatized or passed based on the environment being deployed. Ideally, these kustomizations or whatever method should be kept at the upstream directory of digital ocean

Copy link

@sandaymin123 sandaymin123 Aug 24, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should agree on that tooling first

Copy link

@sandaymin123 sandaymin123 Aug 24, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatively, an operator is the best option but that is more work

Copy link
Contributor

@timoreimann timoreimann Aug 24, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, the approach to customize depends a lot on the tool. For instance, kustomize and kpt can operate on upstream resources that don't support customization whatsoever, whereas Helm charts are (to my knowledge) usually bundled with the upstream source.

We also had an external contributor starting the work to support Helm (#382) but unfortunately couldn't carry the effort onward anymore due to time constraints. We'd be happy to see other contributors step up.

# needed so that any mounts setup inside this container are
# propagated back to the host machine.
mountPropagation: "Bidirectional"
- name: device-dir
mountPath: /dev
volumes:
Expand All @@ -420,6 +425,10 @@ spec:
hostPath:
path: /var/lib/kubelet
type: Directory
- name: kubelet-data-dir
hostPath:
path: /var/data/kubelet
type: Directory
- name: device-dir
hostPath:
path: /dev
Expand Down