On Tue, 8 Jan 2019, Josh Durgin wrote: > On 1/8/19 12:22 PM, Sage Weil wrote: > > I have a question about how to handle mon upgrades to nautilus. Nautilus > > will support the new v2 protocol on port 3300 (which notably will > > support encryption over the wire). By default the mon will bind to both > > the v1 and v2 ports (3300, 6789) for new clusters so that newer clients > > will use the new protocol and older clients the old protocol. > > > > The firewalld.conf file that is included in the ceph package already > > whitelists both ports (the IANA-assigned 3300 was given to us a couple > > years back but we're just now getting around to using it). > > > > So... if there is no firewalling, or firewalld is the firewall being used, > > then having the mons automagically reconfigure themselves to bind to the > > new port when the nautilus upgrade completes would work. > > > > But if someone has a non-standard firewall config, having mons > > reconfigure themselves would mean 3300 would appear in the monmap and > > clients trying to use 3300 would be unable to connect: even if they also > > support 6789, we always prefer (and switch over to) the new 3300 port if > > it is listed. > > Can clients try all addresses, just like they try all monitors? They do during the search phase, but once they get a real monmap, they will close and reopen their session if they are connected on a v1 port and v2 is available. There were several problems this avoided and situations this simplified. sage
