Feat: Ensure mounts survive CSI driver upgrades by splitting out the mount service

[zemul]

• Preserve existing mounts across CSI driver upgrades by moving all weed mount process management into the dedicated seaweedfs-mount daemon. The CSI driver now calculates mount arguments sockets and delegates execution, so the seaweedfs-mount can stay running while the driver pod restarts.
• Deploy seaweedfs-mount as a privileged node daemonset that connect with the driver via /var/lib/seaweefs-mount/seaweefs-mount.sock.

[gemini-code-assist[bot]]

Summary of Changes

Hello @zemul, I'm Gemini Code Assist[^1]! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request implements a crucial architectural enhancement for the SeaweedFS CSI driver by separating the FUSE mount process into a standalone seaweedfs-mount daemon. This change addresses the challenge of mount instability during CSI driver upgrades or restarts. By delegating mount operations to a persistent, privileged DaemonSet, the system ensures that mounted volumes remain available and functional, significantly improving the robustness and reliability of SeaweedFS volumes in Kubernetes environments.

Highlights

• Dedicated Mount Service: Introduced a new seaweedfs-mount daemon responsible for managing FUSE mount processes, decoupling them from the main CSI driver.
• Mount Persistence: This architectural change ensures that existing FUSE mounts survive CSI driver pod restarts or upgrades, significantly enhancing volume availability and robustness.
• CSI Driver Delegation: The CSI driver now delegates mount and unmount operations to the seaweedfs-mount service via a Unix socket, rather than performing them directly.
• New Deployment Artifacts: Added new Dockerfiles, Makefile targets, Helm chart templates, and Kubernetes manifests to facilitate the deployment of the seaweedfs-mount as a privileged DaemonSet.
• Refactored Mounting Logic: The internal pkg/driver/mounter.go has been refactored to utilize a new pkg/mountmanager client for communication with the external mount service.

Ignored Files

• Ignored by pattern: .github/workflows/** (3)
  • .github/workflows/dev.yaml
  • .github/workflows/release.yaml
  • .github/workflows/versioned_release.yaml

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with :thumbsup: and :thumbsdown: on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

[^1]: Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

[zemul]

repair #204

[zemul]

Test conclusion:

1. After deleting the CSI node pod, the seaweedfs-mount DaemonSet kept the per-volume FUSE mounts alive and existing workloads stayed read/write.
2. With two pods sharing the same PVC, restarting the CSI node between them didn’t break the second pod—the driver rehydrated state and NodePublishVolume succeeded.
3. When all pods using the PVC were removed, the controller issued NodeUnstageVolume and the mount service cleanly stopped the weed mount process.
4. No lingering [fusermount] threads or other zombie processes remained once volumes were unstaged.