cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Podkowinski (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-9590) Support for both encrypted and unencrypted native transport connections
Date Fri, 04 Sep 2015 13:07:45 GMT

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

Stefan Podkowinski edited comment on CASSANDRA-9590 at 9/4/15 1:07 PM:
-----------------------------------------------------------------------

Most of the failed tests are upgrade tests that will have to clone and build another Cassandra
version. There's a hardcoded {{GIT_REPO="http://git-wip-us.apache.org/repos/asf/cassandra.git"}}
value that is used in {{ccmlib.repository.clone_development()}}. Unfortunately cloning the
apache repo sometimes won't work in Ubuntu. Running the tests locally on my Ubuntu 14.04 VM
will also fail while building the cluster, with only a useful message left in the ccm log:

{code}
cat ~/.ccm/repository/last.log
Cloning into bare repository '/home/spod/.ccm/repository/_git_cache_apache'...
fatal: unable to access 'https://git1-us-west.apache.org/repos/asf/cassandra.git/': GnuTLS
recv error (-9): A 
TLS packet with unexpected length was received.
{code}

My guess is that the casci Ubuntu VM has the exact same issue with the clone process, that's
why so many of the upgrade tests failed (see [here|http://cassci.datastax.com/job/snazy-9590-3.0-dtest/lastBuild/testReport/upgrade_tests.cql_tests/TestCQL/boolean_test/]
for example). Maybe you can try to run the tests on a different distro? 

Nonetheless at least the repair tests did reveal an [issue|http://cassci.datastax.com/job/snazy-9590-3.0-dtest/lastBuild/testReport/repair_test/TestRepair/dc_repair_test/]
related to the patch, which I've addressed in a new [commit|https://github.com/apache/cassandra/commit/1c1191f0ac7c220e1c28370c7302c438ab98afde].


was (Author: spodxx@gmail.com):
Most of the failed tests are upgrade tests that will have to clone and build another Cassandra
version. There's a hardcoded {{GIT_REPO="http://git-wip-us.apache.org/repos/asf/cassandra.git"}}
value that is used in {{ccmlib.repository.clone_development()}}. Unfortunately cloning the
apache repo sometimes won't work in Ubuntu. Running the tests locally on my Ubuntu 14.04 VM
will also fail while building the cluster, with only a useful message left in the ccm log:

{code}
cat ~/.ccm/repository/last.log
Cloning into bare repository '/home/spod/.ccm/repository/_git_cache_apache'...
fatal: unable to access 'https://git1-us-west.apache.org/repos/asf/cassandra.git/': GnuTLS
recv error (-9): A 
TLS packet with unexpected length was received.
{code}

My guess is that the casci Ubuntu VM has the exact same issue with the clone process, that's
why so many of the upgrade tests failed. Maybe you can try to run the tests on a different
distro? 

Nonetheless at least the repair tests did reveal an [issue|http://cassci.datastax.com/job/snazy-9590-3.0-dtest/lastBuild/testReport/repair_test/TestRepair/dc_repair_test/]
related to the patch, which I've addressed in a new [commit|https://github.com/apache/cassandra/commit/1c1191f0ac7c220e1c28370c7302c438ab98afde].

> Support for both encrypted and unencrypted native transport connections
> -----------------------------------------------------------------------
>
>                 Key: CASSANDRA-9590
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9590
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Stefan Podkowinski
>            Assignee: Stefan Podkowinski
>             Fix For: 2.1.x
>
>         Attachments: nosetest_output.txt
>
>
> Enabling encryption for native transport currently turns SSL exclusively on or off for
the opened socket. Migrating from plain to encrypted requires to migrate all native clients
as well and redeploy all of them at the same time after starting the SSL enabled Cassandra
nodes. 
> This patch would allow to start Cassandra with both an unencrypted and ssl enabled native
port. Clients can connect to either, based whether they support ssl or not.
> This has been implemented by introducing a new {{native_transport_port_ssl}} config option.

> There would be three scenarios:
> * client encryption disabled, {{native_transport_port}} unencrypted, {{native_transport_port_ssl}}
not used
> * client encryption enabled, {{native_transport_port_ssl}} not set, {{native_transport_port}}
encrypted
> * client encryption enabled, {{native_transport_port_ssl}} set, {{native_transport_port}}
unencrypted, {{native_transport_port_ssl}} encrypted
> This approach would keep configuration behavior fully backwards compatible.
> Patch proposal: [Branch|https://github.com/spodkowinski/cassandra/tree/cassandra-9590],
[Diff cassandra-3.0|https://github.com/apache/cassandra/compare/cassandra-3.0...spodkowinski:cassandra-9590],
[Patch against cassandra-3.0|https://github.com/apache/cassandra/compare/cassandra-3.0...spodkowinski:cassandra-9590.patch]
> DTest: [Branch|https://github.com/spodkowinski/cassandra-dtest/tree/cassandra-9590],
[Diff master|https://github.com/riptano/cassandra-dtest/compare/master...spodkowinski:cassandra-9590],
[Pull Request|https://github.com/riptano/cassandra-dtest/pull/530]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message