I think the PR link there was meant to be https://github.com/ceph/ceph/pull/25009 ? :) -Greg On Wed, Dec 5, 2018 at 1:37 PM Sage Weil <sweil@xxxxxxxxxx> wrote: > > The monmap msgr2 branch is is getting close to merge: > > https://github.com/ceph/ceph/pull/25360 > > This has a placeholder protocol in place for now (Ricardo's actual msgr2 > implementation will follow shortly after), but it changes around the rest > of the ceph code to deal with the dual implementations. > > The main visible difference is that entity_addr_t will now render with > either a v1: or v2: prefix, and most places where you used to see a single > addr will now have an entity_addrvec_t. For example, > > $ ceph mon dump > dumped monmap epoch 1 > epoch 1 > fsid 91e4f964-d1f4-4900-835f-de4e3e36c7c7 > last_changed 2018-12-05 12:55:58.578101 > created 2018-12-05 12:55:58.578101 > 0: [v2:127.0.0.1:40376/0,v1:127.0.0.1:40377/0] mon.a > > Same goes for the osdmap, fsmap, mgrmap, etc. > > The parse() method(s) are similarly changed: they understand the v1 and v2 > prefixes, and if no prefix is specified, they (generally) parse a v2 > address. (There are exceptions here with the mon addresses, see below.) > > There are a few new config options, both true by default: > > ms bind msgr1 = true > ms bind msgr2 = true > > There's also > > ms bind ipv4 = true > ms bind ipv6 = false # by default > > Notably, this means daemons can now do dual-stack IPv4 and IPv6 (or will > be able to with some minor fiddling with the client-side code that chooses > which addr to connect to). > > Teuthology's ceph task has a few new options, both true by default, but > set to false for upgrade tasks that start by installing old versions. > These control what addr types the cluster's initial monmap gets: > > overrides: > ceph: > mon_bind_addrvec: true > mon_bind_msgr2: true > > The MonMap::build_initial() method, which is used for creating the initial > monmap during mkfs (if/when the mons are based on mon_host, as they are > with ceph-deploy, but not with teuthology or vstart), will infer whether > an address is v1 or v2 if the port is specified as 6789 or 3300 > respectively. If the port is unspecified, both the v1 and v2 ports are > tried during the MonClient probe stage (once we connect to someone and get > the real monmap then we know for sure). > > > Anyway, please think about any fallout that we might see as a > result of the new rendering or parsing for IP addresses, or anything else > that might be affected by this change! > > Thanks- > sage >
