ReadWriteMany slow and not required

wernight commented 3 months ago

Steps To Reproduce

Set values general.volumeAccessMode=ReadWriteMany and sharedStorageClassName=standard and deploy.

Expected Result

Should work and work faster & cheaper than NFS.

Actual Result

Without any changes this fails with a "Multi-Attach error for volume" error because different Pods try to access the same PVC. For example dataprotection, licences, applogs and secrets-store-inline are shared among 4 or 5 Pods.

Screenshots or Videos

No response

Additional Context

The trick to avoid ReadWriteMany is using ReadWriteOnce which allows multiple Pods on the same Node to use a volume (usually). A more crude alternative is using a single Pod with multiple Containers. Also using ReadOnlyMany for any place that doesn't require writing.

Note: I think this is a bug because I see no reason common alternatives above wouldn't work in this case.

Chart Version

self-host-2024.5.0

Environment Details

No response

Issue Tracking Info

[x] I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.

gecube commented 3 months ago

I totally agree, I think that RWX is overkill and it could be sufficient to use RWO volumes. Unfortunately, it would need massive change in the chart.

gecube commented 3 months ago

another good option could be to replace RWX volume with direct S3 support in the application. And it will be much more scalable than using EFS on EKS.

bitwarden / helm-charts