util: use csi objectuuid for rados locks#6204
Conversation
|
/test ci/centos/mini-e2e-helm/k8s-1.34 |
|
/test ci/centos/mini-e2e/k8s-1.35 |
black-dragon74
force-pushed
the
fix-rados-enametoolong
branch
2 times, most recently
from
44862ba to
d4ce75f
Compare
| defer ioctx.Destroy() | ||
|
|
||
| lock := iolock.NewLock(ioctx, volIDStr, lockName, lockCookie, lockDesc, lockDuration) | ||
| lock := iolock.NewLock(ioctx, objectUUID, lockName, lockCookie, lockDesc, lockDuration) |
There was a problem hiding this comment.
Is this backward compatible?
There was a problem hiding this comment.
Yes, these are transient operation locks at the rados layer. They are not persisted.
There was a problem hiding this comment.
this is fine as long as you have the same ceph-csi version running on all nodes. I don't think we need to support mixed ceph-csi versions.
There was a problem hiding this comment.
what about rolling updates?
| lockName := objectUUID + "-mutexlock" | ||
| lockDesc := "Key rotation mutex lock for " + rv.VolID | ||
| lockCookie := rv.VolID + "-enc-key-rotate" | ||
| lockCookie := objectUUID + "-enc-key-rotate" |
There was a problem hiding this comment.
Again, is this backward compatible?
black-dragon74
force-pushed
the
fix-rados-enametoolong
branch
from
d4ce75f to
27e8a05
Compare
| defer ioctx.Destroy() | ||
|
|
||
| lock := iolock.NewLock(ioctx, volIDStr, lockName, lockCookie, lockDesc, lockDuration) | ||
| lock := iolock.NewLock(ioctx, objectUUID, lockName, lockCookie, lockDesc, lockDuration) |
There was a problem hiding this comment.
this is fine as long as you have the same ceph-csi version running on all nodes. I don't think we need to support mixed ceph-csi versions.
|
@Mergifyio rebase |
CSI vol ids > 100bytes fail with error `ENAMETOOLONG`
when acquiring rados lock as ceph sets default value
for `osd_max_attr_name_len` to 100.
This patch fixes the issue by decomposing the CSI ID
and using the ObjectUUID to ensure the lock names
are always < 100 bytes ("lock." + UUID + "-mutexlock"" = 51bytes).
"lock."(5 bytes) is a prefix applied by Ceph internally for every
lock name so we can only pass lock names that are <= 95bytes.
The hash based approach is not used to keep things
debuggable.
Fixes: ceph#5419
Signed-off-by: Niraj Yadav <niryadav@redhat.com>
✅ Branch has been successfully rebased |
ceph-csi-bot
force-pushed
the
fix-rados-enametoolong
branch
from
27e8a05 to
da69d2f
Compare
|
/test ci/centos/upgrade-tests-cephfs |
|
/test ci/centos/k8s-e2e-external-storage/1.33 |
|
/test ci/centos/k8s-e2e-external-storage/1.34 |
|
/test ci/centos/upgrade-tests-rbd |
|
/test ci/centos/mini-e2e-helm/k8s-1.33 |
|
/test ci/centos/mini-e2e-helm/k8s-1.34 |
|
/test ci/centos/mini-e2e/k8s-1.33 |
|
/test ci/centos/mini-e2e/k8s-1.34 |
|
/test ci/centos/k8s-e2e-external-storage/1.35 |
|
/test ci/centos/mini-e2e-helm/k8s-1.35 |
|
/test ci/centos/mini-e2e/k8s-1.35 |
Merge Queue Status
This pull request spent 11 seconds in the queue, including 2 seconds running CI. Required conditions to merge
|
5 participants
Describe what this PR does
CSI vol ids > 100bytes fail with error
ENAMETOOLONGwhen acquiring rados lock as ceph sets default value forosd_max_attr_name_lento 100.This patch fixes the issue by decomposing the CSI ID and using the ObjectUUID to ensure the lock names are always < 100 bytes ("lock." + UUID + "-mutexlock"" = 51bytes).
"lock."(5 bytes) is a prefix applied by Ceph internally for every lock name so we can only pass lock names that are <= 95bytes.
The hash based approach is not used to keep things debuggable.
Fixes: #5419