[ 
https://issues.apache.org/jira/browse/CASSANDRA-10404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16170646#comment-16170646
 ] 

Jason Brown edited comment on CASSANDRA-10404 at 9/18/17 8:42 PM:
------------------------------------------------------------------

Now that CASSANDRA-8457 is committed, here's the updated version of this patch 
for review. The goals of this ticket are the same as stated in the earlier 
commentary.

||10404||
|[branch|https://github.com/jasobrown/cassandra/tree/10404]|
|[dtest-code|https://github.com/jasobrown/cassandra-dtest/tree/10404-dtest]|
|[ccm-code|https://github.com/jasobrown/ccm/tree/10404]|
|[utests|https://circleci.com/gh/jasobrown/cassandra/tree/10404]|

(Note: it doesn't make sense to run the dtests on CI as they are guaranteed to 
break without the dtest patches, as well).

The only tricky part is during rolling cluster upgrades from 3.0/3.X to 4.0, 
where an upgraded node, after bouncing, doesn't know the version of a peer (and 
we're using TLS). We try with the currently known version of the peer (by 
default {{MessagingService#current_version}}, but if that fails, we'll recheck 
{{MessagingService#versions}} on each reconnect attempt to see if the peer 
tried to connect to the local node, at which point we grab it's version and set 
into {{MessagingService#versions}}.

This change requires changes to dtests, and as well as an update to ccm itself. 
The two-line ccm change is required as several dtests call into ccm's 
{{cluster#enable_internode_ssl()}}, and we now need to set the {{enabled}} yaml 
property to true by default for those tests (and probably for ccm, as well, 
when it uses TLS).

[~spo...@gmail.com] Would you be willing to review, please?


was (Author: jasobrown):
Now that CASSANDRA-8457 is committed, here's the updated version of this patch 
for review. The goals of this ticket are the same as stated in the earlier 
commentary.

||10404||
|[branch|https://github.com/jasobrown/cassandra/tree/10404]|
|[dtest-code|https://github.com/jasobrown/cassandra-dtest/tree/10404-dtest]|
|[ccm-code|https://github.com/jasobrown/ccm/tree/10404]|
|[utests|https://circleci.com/gh/jasobrown/cassandra/tree/10404]|

(Note: it doesn't make sense to run the dtests on CI as they are guaranteed to 
break without the dtest patches, as well).

The only tricky part is during rolling cluster upgrades from 3.0/3.X to 4.0, 
where an upgraded node doesn't know the version of a peer (and we're using 
TLS). We try with the currently known version od the peer (by default 
{{MessagingService#current_version}}, but if that fails, we'll recheck 
{{MessagingService#versions}} on each reconnect attempt to see if the peer 
tried to connect to the local node, at which point we grab it's version and set 
into {{MessagingService#versions}}.

This change requires changes to dtests, and as well as an update to ccm itself. 
The two-line ccm change is required as several dtests call into ccm's 
{{cluster#enable_internode_ssl()}}, and we now need to set the {{enabled}} yaml 
property to true by default for those tests (and probably for ccm, as well, 
when it uses TLS).

[~spo...@gmail.com] Would you be willing to review, please?

> Node to Node encryption transitional mode
> -----------------------------------------
>
>                 Key: CASSANDRA-10404
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10404
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Tom Lewis
>            Assignee: Jason Brown
>
> Create a transitional mode for encryption that allows encrypted and 
> unencrypted traffic node-to-node during a change over to encryption from 
> unencrypted. This alleviates downtime during the switch.
>  This is similar to CASSANDRA-10559 which is intended for client-to-node



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to