> For existing versions what about having a “default ssl” or “default no SSL” > yaml setting which decides what port is advertised? Then someone could still > connect on the other port manually specifying. Then new column can be added > with the new table in trunk.
I'm assuming "advertisement" here includes which port is in system.peers(_v2) and is included in status and topology events. If dual-native-port is enabled, a client is connecting unencrypted to the non-SSL port, and "advertise-native-port=ssl" (name pending) is enabled, then when that client fetches peers it will get the SSL ports, right? If the client doesn't support SSL, then those subsequent connections will fail. An operator would have to set "advertise-native-port=ssl" and override the port options in all clients, which isn't feasible. It might be possible to move to a system view, and return the right native port depending on whether the connection the query originates from is SSL or not. So if a control connection is over SSL, then ports in system_views.peers_ssl_aware (name pending) would be SSL ports. But having query responses dependent on connection state seems like a recipe for a very weird bug in the future. I still think deprecating dual-native-port is the cleanest and most compatible solution, especially since it would address a few other related bugs as well. I'm considering a separate thread to get consensus on that. Abe
