On Tue, 4 Jul 2017, Bosom Tabby wrote: > Hi Sage, > > Finally getting around to this one. Great! > > I think this is the way to go, and I don't think it will be *that* > > involved. Probably it just requires an option to supplement public_addr > > with bind_addr. As long as the Messenger myaddr field is populated with > > the public_addr (and not bind_addr) field I suspect everything will Just > > Work. Peers connecting to us will see the public_addr for their > > getpeeraddr config and that's the one that the messenger will advertise > > during its handshake; bind_addr would be used *only* by the actual bind > > call. Does that seem reasonable? > > There is a fair amount of logic around public_addr that makes this a little more > complex. For example, we automatically select the public_addr using pick_addresses > when public_network is set. Also we have logic that attempts to discover available ports, > and “rebinds” the socket which we would want to carry over to the proposed “bind_addr”. > > I think it might be easier to go in the other direction. i.e, introduce “mon_advertise_addr” > which overrides msgr->my_inst->addr and be used on the network to reach the mons. If > empty (default) advertise_addr will be set to the effective value of public_addr. If set it must be an > ip address or resolvable DNS name. If a port is specified it will be used, otherwise > CEPH_MON_PORT is assumed. > > Finally, by using the “mon_” prefix this makes it clear that this is limited to MONs where its needed. > While its possible to do with for OSD, MDS, etc. I think it unnecessarily increases the config surface area. > > What do you think? Yeah, that sounds reasonable to me. Can you elaborate on how the kubernetes side of this approach will work? Thanks! sage
