do not udevadm trigger, ceph-disk does it

[ghost]

There is no need for osd create to call udevadm trigger action=add. By
running all actions associated with add for all block devices, it may
also trigger some race conditions. For instance, the following happens
about 10% of the time, when using dmcrypt:

• ceph-disk prepare --dmcrypt /dev/vdb
• /dev/vdb1 starts activating via udev
• ceph-deploy triggers action=add
• /dev/vdb2 udev chown root /dev/vdb2
• /dev/vdb1 activate fails because of permission denied on /dev/vdb2
• /dev/vdb2 udev action chown ceph /dev/vdb2

http://tracker.ceph.com/issues/13299 Fixes: #13299

Signed-off-by: Loic Dachary loic@dachary.org

[ceph-jenkins]

Refer to this link for build results (access rights to CI server needed):
http://jenkins.ceph.com//job/ceph-deploy-pull-requests/1798/
Test PASSed.

[liewegas]

Nice catch! Can you retarget this at infernalis branch?

Which udev rule is doing the root chown? Is that anything that is in our control? It seems like we avoid the situation most of the time now but the possibliity is always there that we'll get unlucky...

[liewegas]

in any case, Reviewed-by:

[ghost]

Which udev rule is doing the root chown? Is that anything that is in our control? It seems like we avoid the situation most of the time now but the possibliity is always there that we'll get unlucky...

It is my understanding that when a udev rule starts, it chown root (or recreate the file maybe, with default owner ?) and then the chown happens shortly afterwards but that leaves a window of opportunity.

[liewegas]

Perhaps the "fix" is to not blindly trigger events on all devices, but only on the specific device that changes?

[codenrhoden]

When looking at some of the ceph-disk changes recently, I saw that it seemed to do all the necessary udevadm calls needed, and that made me think of places I had seen it in ceph-deploy and wonder if those were still necessary.

Glad to see this cleanup! Thanks a bunch.

[ghost]

Perhaps the "fix" is to not blindly trigger events on all devices, but only on the specific device that changes?

I think that's what ceph-disk does now.

[ghost]

When looking at some of the ceph-disk changes recently, I saw that it seemed to do all the necessary udevadm calls needed

It always did the necessary udevadm / partprobe. The bugs were when it did too many and it created race conditions. For instance calling partprobe actually removes devices before adding them again. I let you imagine what that can do to an ongoing osd activation :-)