Project

General

Profile

Actions

Documentation #40996

open

Calling messenger v1 protocol legacy is misleading

Added by Lucas Zanella over 4 years ago. Updated over 4 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
% Done:

0%

Tags:
Backport:
Reviewed:
Affected Versions:

Description

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

Doc Ref.: https://docs.ceph.com/docs/master/rados/configuration/msgr2/

many thanks & br
lucas

Actions #2

Updated by Greg Farnum over 4 years ago

  • Project changed from Ceph to rbd
  • Category deleted (documentation)

Is there something weird going on with rbd? I imagine the example command is just invoking a kernel interface that runs v1-only so perhaps we need to be clearer about what "pre-Nautilus" means?

Actions #3

Updated by Jason Dillaman over 4 years ago

  • Project changed from rbd to Linux kernel client
Actions #4

Updated by Jason Dillaman over 4 years ago

The kernel "libceph" driver does not support the v2 protocol.

Actions #5

Updated by Lucas Zanella over 4 years 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.

Actions #6

Updated by Lucas Zanella over 4 years ago

excuse me, I explained the wrong way - to be correct now:
"ceph -s" and "rbd disable feature..." uses V2
and "rbd map..." uses V1

Actions #7

Updated by Jason Dillaman over 4 years 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).

Actions #8

Updated by Jason Dillaman over 4 years ago

... our comments raced. Just sounds like there is confusion in that the kernel will continue to use the legacy v1 protocol (since the kernel drivers are not tied to a Ceph release -- i.e. there is no Nautilus krbd).

Actions #9

Updated by Lucas Zanella over 4 years 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.

Actions #10

Updated by Jeff Layton over 4 years 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.

Actions

Also available in: Atom PDF