Re: [Discuss] CASSANDRA-16999 introduction of a column in system.peers_v2

+1 to deprecating dual ports and removing in 5.0 On Tue, Feb 13, 2024 at 4:29 AM Štefan Miklošovič < stefan.mikloso...@gmail.com> wrote: > Alright ... so how I am interpreting this, even more so after Sam's and > Brandon's mail, is that we should just get rid of that completely in trunk > and de

Re: [Discuss] CASSANDRA-16999 introduction of a column in system.peers_v2

Alright ... so how I am interpreting this, even more so after Sam's and Brandon's mail, is that we should just get rid of that completely in trunk and deprecate in 5.0. There are already patches for 3.x and 4.x branches of the driver so the way I was looking at that was that we might resurrect th

Re: [Discuss] CASSANDRA-16999 introduction of a column in system.peers_v2

On Tue, Feb 13, 2024 at 6:17 AM Sam Tunnicliffe wrote: > Also, if CASSANDRA-16999 is only going to trunk, why can't we just deprecate > dual ports in 5.0 (as it isn't at -rc stage yet) and remove it from trunk? > That seems preferable to shoehorning something into the new > system_views.peers t

Re: [Discuss] CASSANDRA-16999 introduction of a column in system.peers_v2

Late to the party I'm afraid, but I'd agree with Abe's proposal to deprecate the dual port approach given that CASSANDRA-10559 makes it pretty much redundant. Adding further yaml options like "default ssl/no ssl" feels like another nasty band-aid that we'll have to live with for the foreseeable

Re: [Discuss] CASSANDRA-16999 introduction of a column in system.peers_v2

I think that the situation like client_encryption_options.enabled = true client_encryption_options.optional=true native_transport_port != native_transport_port_ssl is a legit bug and should be fixed. If we look here (1), when these ports are not equal, the normal port is explicitly set to be unen

Re: [Discuss] CASSANDRA-16999 introduction of a column in system.peers_v2

> Deprecating helps nothing for existing releases. We can’t/shouldn’t remove > the feature in existing releases. The deprecation I'm proposing is intended to push people to configure their servers in a way that is more secure and maximizes compatibility with clients. Deprecating can help for ex

Re: [Discuss] CASSANDRA-16999 introduction of a column in system.peers_v2

Correct. But that initial connection will work and the client will work, it just won’t have connections to multiple nodes. I didn’t say it’s optimal, but this is the best way I can see that doesn’t break things more than they are now, and does give an improvement because you can pick which port

Re: [Discuss] CASSANDRA-16999 introduction of a column in system.peers_v2

> 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

Re: [Discuss] CASSANDRA-16999 introduction of a column in system.peers_v2

We should not introduce a new column in a patch release. From what I have seen many drivers “select * from peers”, yes it’s not a good idea, but we can’t control what all clients do, and an extra column coming back may break the processing of that.For existing versions what about having a “default

Re: [Discuss] CASSANDRA-16999 introduction of a column in system.peers_v2

Honest to god, I do not know, Abe. If I see a feedback where we reach consensus to deprecate dual port support, I will deprecate that. On Wed, Feb 7, 2024 at 12:42 PM Abe Ratnofsky wrote: > CASSANDRA-9590 (Support for both encrypted and unencrypted native > transport connections) was implemented

Re: [Discuss] CASSANDRA-16999 introduction of a column in system.peers_v2

CASSANDRA-9590 (Support for both encrypted and unencrypted native transport connections) was implemented before CASSANDRA-10559 (Support encrypted and plain traffic on the same port), but both been available since 3.0. On 9590, STARTTLS was considered, but rejected due to the changes that would

Re: [Discuss] CASSANDRA-16999 introduction of a column in system.peers_v2

More context behind dual native port support might be found here https://issues.apache.org/jira/browse/CASSANDRA-9590 where it was implemented. On Wed, Feb 7, 2024 at 12:07 PM Abe Ratnofsky wrote: > What is the audience for dual-native-port operation? My understanding is > that most users can us

Re: [Discuss] CASSANDRA-16999 introduction of a column in system.peers_v2

What is the audience for dual-native-port operation? My understanding is that most users can use a single port for optional SSL, ever since CASSANDRA-10559 . Using a single port for both encrypted and unencrypted traffic also makes clients m

[Discuss] CASSANDRA-16999 introduction of a column in system.peers_v2

Hi list, there is CASSANDRA-16999 which introduces native_port_ssl into system.peers_v2 table. The reasoning behind that is that without this, Cassandra Java Driver (both 3.x and 4.x branches) are not able to discover nodes when dual no-ssl / ssl communication is enabled. To be more specific, if