Calling messenger v1 protocol legacy is misleading
Ceph clients (14.2.2) still need both versions of messenger protocol (v1 and v2) in order to work
but docs pretend v1 to be legacy which is misleading since it's still necessary for commands like
rbd device map mypool/myimage1 --id myuser
many thanks & br
#5 Updated by Lucas Zanella 6 months ago
Hi thanks for reply,
the claimed version is 14.2.2 (nautlius) and not a "pre-Nautilus" ceph installation.
If someone uses e.g. "ceph -s" from a client, communication is handled using v1.
Same when using "rbd disable feature..." but as soon as we are tryin to map image
by "rbd map..." communication switches protocol to v2. What is kind of unexpected
behavior when reading v1 as legacy protocol.
It could be stated clear that even that v2 is going to substitute v1 in further releases
it is still required yet - if you agree with me.
But anyway thanks for your time.
#7 Updated by Jason Dillaman 6 months ago
I guess I don't understand the issue. The definition of "legacy" as per Google is "denoting or relating to software or hardware that has been superseded but is difficult to replace because of its wide use.".
If someone uses "ceph -s" from a pre-Nautilus client, it will use v1. Nautilus and later should default to v2 if available on the MON address list. Similarly, all "rbd" CLI commands for Nautilus and later will use v2 (if available), but the kernel's libceph driver will continue to use v1 (the rbd CLI pokes and prods sysfs to configure krbd and libceph by extension).
#9 Updated by Lucas Zanella 6 months ago
exactly, that's what confused us and it took a while to realize that port 6789 needs to be reachable in addition to port 3300. And of course you are right about definition of legacy sw but if it would be stated more clear (as you just did) other could be prevented from running into the same situation. As a thought.
#10 Updated by Jeff Layton 5 months ago
I don't see this as a problem.
The kernel client just lags the userland code a bit here, and doesn't have msgr2 support yet. Eventually we'll get that piece done, and then there will be little need to keep v1 ports open.
Maybe the docs could use some clarification there, but I'm not sure where.