-
Notifications
You must be signed in to change notification settings - Fork 28
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
RWX support and stability improvement #43
Conversation
Signed-off-by: Vicente Cheng <[email protected]>
Signed-off-by: Vicente Cheng <[email protected]>
72cf02d
to
c28f8af
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, with the disclaimer that I'm not super-familiar with this part of the harvester codebase yet :-)
I wanted to check about the introduction of networkfs-manager. I assume we have this so that in future we can potentially support RWX volumes from non-Longhorn storage backends? My second question about that is: do we also need a PR against harvester to deploy that piece?
I also found https://docs.harvesterhci.io/v1.4/rancher/csi-driver/ which has the following note, which will want updating/removing once this feature goes in:
Currently, the Harvester CSI driver only supports single-node read-write(RWO) volumes. Please follow the issue #1992 for future multi-node read-only(ROX) and read-write(RWX) support.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
Thanks @tserong, You are correct. We need to make some changes on the harvester side, like adding this new component and the new RBAC configuration.
Indeed, we also need to update the document for detailed examples of users using RWX volume on the downstream clusters. Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for the PR. Will the Harvester chart update with networkfs-manager ?
8ad6135
to
c28f8af
Compare
Harvester CSI driver rely on the Longhorn volume for the RWO PVC on the downstream cluster. Currently, we did not check the volume status after removing it from VM. That might involve the longhorn volume migration flow. It will increase the potential risk. We need to make sure the corresponding volume is detached then we can try to attached (to VM) again on the migration target node. Then we can avoid the LH volume migration and it should make the workload migration on the downstream cluster more stable. So, we could check the deatched state of volume or attached to the correct node on the ControllerPublish stage. Signed-off-by: Vicente Cheng <[email protected]>
Signed-off-by: Vicente Cheng <[email protected]>
Signed-off-by: Vicente Cheng <[email protected]>
c28f8af
to
3df118d
Compare
I mixed two things because I developed the RWX feature based on the stability improvement.
I apologize for this. I thought the reviewers were the same, so please help to review it!
stability: f6b6c5a
RWX: c28f8af
IMPORTANT: Please do not create a Pull Request without creating an issue first.
Problem:
Solution:
Related Issue:
Stability:
RWX:
Test plan:
Volume Stability Test Plan
https://gist.github.com/Vicente-Cheng/8e635a2c0ca649d7256419d61a680b3d
We could increase the volumes to 10, 15, 20, 30, or 40 to ensure stability.
RWX Support Test Plan
Prerequisites
networkfilesystems
is for the RWX (we also need the new controller (https://github.com/harvester/networkfs-manager)volumes
is for the stability checkingnetworkfs-manager
Test Steps
Please complete the
Prerequisites
first1.1 (Options) create storage network
1.2 (Options) enable RWX volume with storage network on Longhorn (REF: https://longhorn.io/docs/1.7.0/advanced-resources/deploy/storage-network/#setting-storage-network-for-rwx-volumes)
2.1 (Options) if we enable storage network for RWX volume (on Longhorn), please also add this storage network to the VM for the guest cluster