The problem would only happen if radosgw is enabled (radosgw.pp is the only manifest that modifies ceph.conf outside of primary mon), AND if ceph-osd role is assigned to secondary controllers. Here's what happens:
1) ceph-deploy config pull downloads ceph.conf from primary mon
2) all other ceph-deploy invokations done for secondary controller role are not affected since ceph.conf is not touched until:
3) radosgw.pp (running as part of controller role) modifies ceph.conf to update radosgw\host variable
4) there's no more ceph-deploy invokations done after radosgw.pp for controller, so controller deployment succeeds
5) ceph-osd role starts with ceph-deploy osd prepare which fails due to ceph.conf in /root and /etc/ceph being out of sync after radosgw.pp updates in (3)
The fix is to make sure /root/ceph.conf is updated after /etc/ceph/ceph.conf is modified before any other ceph-deploy commands.
The problem would only happen if radosgw is enabled (radosgw.pp is the only manifest that modifies ceph.conf outside of primary mon), AND if ceph-osd role is assigned to secondary controllers. Here's what happens:
1) ceph-deploy config pull downloads ceph.conf from primary mon
2) all other ceph-deploy invokations done for secondary controller role are not affected since ceph.conf is not touched until:
3) radosgw.pp (running as part of controller role) modifies ceph.conf to update radosgw\host variable
4) there's no more ceph-deploy invokations done after radosgw.pp for controller, so controller deployment succeeds
5) ceph-osd role starts with ceph-deploy osd prepare which fails due to ceph.conf in /root and /etc/ceph being out of sync after radosgw.pp updates in (3)
The fix is to make sure /root/ceph.conf is updated after /etc/ceph/ceph.conf is modified before any other ceph-deploy commands.