Hi Stefan, If ceph-mon respected ms_bind_msgr1 = false, then one could add --ms-bind-msgr1=false as extra_entrypoint_args in the mon service_type [1], so as to have any ceph-mon daemons deployed or redeployed using msgr v2 exclusively. Unfortunately, ceph-mon doesn't respect this setting as suspected by Ilya here [2] and confirmed on a test cluster on my side. I think we can make this a tracker. As for your other question as to when v1 will be disabled by default on new Ceph clusters, I have no idea at all. Cheers, Frédéric. [1] https://docs.ceph.com/en/quincy/cephadm/services/#extra-entrypoint-arguments [2] https://www.spinics.net/lists/ceph-users/msg73320.html ----- Le 13 Mar 25, à 14:30, Stefan Kooman stefan@bit.nl a écrit :
Hi,
For new clusters one of the first things I do is to disable messenger v1:
ceph config set mon ms_bind_msgr1 false
However, that is not enough, as a restart of the monitors will leave v1 enabled in the monmap. Why is that? That looks like a bug to me.
Therefore I explicitly set the addrs and port of the monitors, i.e.:
ceph mon set-addrs stefan-ceph-test01 $ip:3300 Be careful not to make a typo, that will ruin your day, see [1].
This immediately disables v1 and a new monmap is created.
All good, however ...
When a monitor is removed, say mon1, and added again, the new mon is added with both a v1 and a v2 address. I don't want that, I want to disable legacy v1 permanently. How do I do that?
Adding:
[mon] ms_bind_msgr1 = false
to /etc/ceph/ceph.conf does not help either.
When I performed a test this morning on a fresh 18.2.4 cluster (remove a mon, add it back again) to reproduce this issue the v1 was enabled again on two monitors (a third was left with only v2).
Repeating the "ceph mon set-addrs" command removes the v1 binding again. But I would like to avoid messing around with this, triggering monmaps / elections, especially when making an error with this brings your cluster to a halt [1].
In what Ceph release will v1 be disabled by default on new clusters?
Gr. Stefan
[1] https://tracker.ceph.com/issues/54744 _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io