do not udevadm trigger, ceph-disk does it

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>

diff --git a/ceph_deploy/osd.py b/ceph_deploy/osd.py
index 7bc930216d75afdab5eea645e900f9642005526c..e797fb92783f22a2fe3650743836c5b0c3cff7eb 100644 (file)
--- a/ceph_deploy/osd.py
+++ b/ceph_deploy/osd.py
@@ -42,16 +42,6 @@ def create_osd(conn, cluster, key):
         logger.warning('osd keyring does not exist yet, creating one')
         conn.remote_module.write_keyring(path, key)
 
-    return remoto.process.run(
-        conn,
-        [
-            'udevadm',
-            'trigger',
-            '--subsystem-match=block',
-            '--action=add',
-        ],
-    )
-
 
 def osd_tree(conn, cluster):
     """
@@ -240,16 +230,6 @@ def prepare_disk(
             system.enable_service(conn, "ceph.target")
         elif init == 'sysvinit':
             system.enable_service(conn, "ceph")
-        
-        return remoto.process.run(
-            conn,
-            [
-                'udevadm',
-                'trigger',
-                '--subsystem-match=block',
-                '--action=add',
-            ],
-        )
 
 
 def exceeds_max_osds(args, reasonable=20):