[
https://issues.apache.org/jira/browse/CASSANDRA-16362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17268732#comment-17268732
]
Alexander Dejanovski commented on CASSANDRA-16362:
--------------------------------------------------
Hi [~jmeredithco],
very sorry for not responding earlier, I'm heads down on 4.0 repair quality
testing at the moment.
A colleague of mine is working on giving you steps to reproduce the issue with
ccm and will comment here soon with the instructions.
For Medusa integration tests, there have been issues with the sstableloader
test (scenario 11) which was fixed by CASSANDRA-16280.
I manage to get the scenario 11 passing with beta3:
{code:java}
(py36) adejanovski@mac-alex-2 cassandra-medusa % ./run_integration_tests.sh -t
11 --cassandra-version=4.0-beta3
...
...
@11 @local
Scenario Outline: Perform a backup, and restore it using the sstableloader --
@1.1 Local storage # integration/features/integration_tests.feature:450
Given I have a fresh ccm cluster "with_client_encryption" running named
"scenario11" # features/steps/integration_steps.py:125
Given I have a fresh ccm cluster "with_client_encryption" running named
"scenario11" # features/steps/integration_steps.py:125 22.497s
Given I am using "local" as storage provider in ccm cluster
"with_client_encryption" # features/steps/integration_steps.py:235
0.052s
When I create the "test" table in keyspace "medusa"
# features/steps/integration_steps.py:511 0.122s
When I load 100 rows in the "medusa.test" table
# features/steps/integration_steps.py:534 0.192s
When I run a "ccm node1 nodetool flush" command
# features/steps/integration_steps.py:542 1.508s
When I load 100 rows in the "medusa.test" table
# features/steps/integration_steps.py:534 0.160s
When I run a "ccm node1 nodetool flush" command
# features/steps/integration_steps.py:542 1.445s
When I perform a backup in "full" mode of the node named "first_backup"
# features/steps/integration_steps.py:547 3.208s
Then I can see the backup named "first_backup" when I list the backups
# features/steps/integration_steps.py:591 0.014s
Then I can verify the backup named "first_backup" successfully
# features/steps/integration_steps.py:655 0.029s
When I load 100 rows in the "medusa.test" table
# features/steps/integration_steps.py:534 0.135s
When I run a "ccm node1 nodetool flush" command
# features/steps/integration_steps.py:542 1.373s
Then I have 300 rows in the "medusa.test" table in ccm cluster
"with_client_encryption" # features/steps/integration_steps.py:766
0.119s
When I truncate the "medusa.test" table in ccm cluster
"with_client_encryption" #
features/steps/integration_steps.py:1040 0.167s
When I restore the backup named "first_backup" with the sstableloader
# features/steps/integration_steps.py:734 20.214s
Then I have 200 rows in the "medusa.test" table in ccm cluster
"with_client_encryption" # features/steps/integration_steps.py:766
0.079s
...
...
1 feature passed, 0 failed, 0 skipped
1 scenario passed, 0 failed, 59 skipped
16 steps passed, 0 failed, 1039 skipped, 0 undefined
Took 0m51.312s
{code}
But it fails with beta4 due to the issue reported in this very ticket:
{noformat}
./run_integration_tests.sh -t 11 --cassandra-version=4.0-beta4
...
...
@11 @local
Scenario Outline: Perform a backup, and restore it using the sstableloader --
@1.1 Local storage # integration/features/integration_tests.feature:450
Given I have a fresh ccm cluster "with_client_encryption" running named
"scenario11" # features/steps/integration_steps.py:125
Given I have a fresh ccm cluster "with_client_encryption" running named
"scenario11" # features/steps/integration_steps.py:125 22.836s
Given I am using "local" as storage provider in ccm cluster
"with_client_encryption" # features/steps/integration_steps.py:235
0.053s
When I create the "test" table in keyspace "medusa"
# features/steps/integration_steps.py:511 0.113s
When I load 100 rows in the "medusa.test" table
# features/steps/integration_steps.py:534 0.229s
When I run a "ccm node1 nodetool flush" command
# features/steps/integration_steps.py:542 1.424s
When I load 100 rows in the "medusa.test" table
# features/steps/integration_steps.py:534 0.149s
When I run a "ccm node1 nodetool flush" command
# features/steps/integration_steps.py:542 1.208s
When I perform a backup in "full" mode of the node named "first_backup"
# features/steps/integration_steps.py:547 2.832s
Then I can see the backup named "first_backup" when I list the backups
# features/steps/integration_steps.py:591 0.013s
Then I can verify the backup named "first_backup" successfully
# features/steps/integration_steps.py:655 0.025s
When I load 100 rows in the "medusa.test" table
# features/steps/integration_steps.py:534 0.109s
When I run a "ccm node1 nodetool flush" command
# features/steps/integration_steps.py:542 1.213s
Then I have 300 rows in the "medusa.test" table in ccm cluster
"with_client_encryption" # features/steps/integration_steps.py:766
0.099s
When I truncate the "medusa.test" table in ccm cluster
"with_client_encryption" #
features/steps/integration_steps.py:1040 0.162s
When I restore the backup named "first_backup" with the sstableloader
# features/steps/integration_steps.py:734
Exception in thread "main" java.lang.RuntimeException: Could not create SSL
Context.
at
org.apache.cassandra.tools.BulkLoader.buildSSLOptions(BulkLoader.java:261)
at org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:64)
at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:49)
Caused by: java.io.IOException: Error creating/initializing the SSL Context
at
org.apache.cassandra.security.SSLFactory.createSSLContext(SSLFactory.java:184)
at
org.apache.cassandra.tools.BulkLoader.buildSSLOptions(BulkLoader.java:257)
... 2 more
Caused by: java.lang.IllegalStateException: SSLContextImpl is not initialized
at
sun.security.ssl.SSLContextImpl.engineGetSocketFactory(SSLContextImpl.java:172)
at javax.net.ssl.SSLContextSpi.getDefaultSocket(SSLContextSpi.java:142)
at
javax.net.ssl.SSLContextSpi.engineGetDefaultSSLParameters(SSLContextSpi.java:168)
at javax.net.ssl.SSLContext.getDefaultSSLParameters(SSLContext.java:419)
at
org.apache.cassandra.security.SSLFactory.createSSLContext(SSLFactory.java:178)
When I restore the backup named "first_backup" with the sstableloader
# features/steps/integration_steps.py:734 1.635s
Traceback (most recent call last):
File
"/Users/adejanovski/projets/cassandra/thelastpickle/py36/lib/python3.6/site-packages/behave/model.py",
line 1329, in run
match.run(runner.context)
File
"/Users/adejanovski/projets/cassandra/thelastpickle/py36/lib/python3.6/site-packages/behave/matchers.py",
line 98, in run
self.func(context, *args, **kwargs)
File "features/steps/integration_steps.py", line 746, in
_i_restore_the_backup_named_with_sstableloader
use_sstableloader=True,
File
"/Users/adejanovski/projets/cassandra/thelastpickle/cassandra-medusa/medusa/restore_node.py",
line 53, in restore_node
keyspaces, tables)
File
"/Users/adejanovski/projets/cassandra/thelastpickle/cassandra-medusa/medusa/restore_node.py",
line 172, in restore_node_sstableloader
invoke_sstableloader(config, download_dir, keep_auth,
fqtns_to_restore, cassandra.storage_port)
File
"/Users/adejanovski/projets/cassandra/thelastpickle/cassandra-medusa/medusa/restore_node.py",
line 219, in invoke_sstableloader
output = subprocess.check_output(sstableloader_args)
File
"/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6/lib/python3.6/subprocess.py",
line 336, in check_output
**kwargs).stdout
File
"/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6/lib/python3.6/subprocess.py",
line 418, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command
'['/Users/adejanovski/.ccm/repository/4.0-beta4/bin/sstableloader', '-d',
'127.0.0.1', '--conf-path',
'/Users/adejanovski/.ccm/scenario11/node1/conf/cassandra.yaml', '--username',
'cassandra', '--password', 'cassandra', '--no-progress',
'/tmp/medusa-restore-a72a47c8-8776-4de4-9cc1-d5eea23cf434/medusa/test-b9d0a8705b4611eb8be0ede3aec9ec61',
'-ts',
'/Users/adejanovski/projets/cassandra/thelastpickle/cassandra-medusa/tests/resources/local_with_ssl/generic-server-truststore.jks',
'-tspw', 'truststorePass1', '-ks',
'/Users/adejanovski/projets/cassandra/thelastpickle/cassandra-medusa/tests/resources/local_with_ssl/127.0.0.1.jks',
'-kspw', 'testdata1']' returned non-zero exit status 1.
{noformat}
With trunk now, and since the changes from this ticket were committed, we fail
earlier as we cannot connect anymore using the python driver:
{noformat}
./run_integration_tests.sh -t 1 --cassandra-version=github:apache/trunk
..
..
..
@11 @local
Scenario Outline: Perform a backup, and restore it using the sstableloader --
@1.1 Local storage # integration/features/integration_tests.feature:450
Given I have a fresh ccm cluster "with_client_encryption" running named
"scenario11" # features/steps/integration_steps.py:125
https://github.com/apache/cassandra.git github:apache/trunk
18:44:54,558 ccm INFO Fetching Cassandra updates...
18:44:55,978 ccm DEBUG Branch up to date, not pulling.
Given I have a fresh ccm cluster "with_client_encryption" running named
"scenario11" # features/steps/integration_steps.py:125 115.170s
Given I am using "local" as storage provider in ccm cluster
"with_client_encryption" # features/steps/integration_steps.py:235
0.046s
When I create the "test" table in keyspace "medusa"
# features/steps/integration_steps.py:511 0.001s
Traceback (most recent call last):
File
"/Users/adejanovski/projets/cassandra/thelastpickle/py36/lib/python3.6/site-packages/behave/model.py",
line 1329, in run
match.run(runner.context)
File
"/Users/adejanovski/projets/cassandra/thelastpickle/py36/lib/python3.6/site-packages/behave/matchers.py",
line 98, in run
self.func(context, *args, **kwargs)
File "features/steps/integration_steps.py", line 515, in
_i_create_the_whatever_table
context.session.execute(keyspace.format(keyspace_name))
AttributeError: 'NoneType' object has no attribute 'execute'
...
...
{noformat}
Using the ccm cluster generated by this last test, we tried to connect to it
with the Python driver using both TLS1.1 and 1.2 without success.
> SSLFactory should initialize SSLContext before setting protocols
> ----------------------------------------------------------------
>
> Key: CASSANDRA-16362
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16362
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
> Reporter: Erik Merkle
> Assignee: Jon Meredith
> Priority: Normal
> Fix For: 4.0-beta5
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Trying to use sstableloader from the latest trunk produced the following
> Exception:
> {quote}
> Exception in thread "main" java.lang.RuntimeException: Could not create SSL
> Context.
> at
> org.apache.cassandra.tools.BulkLoader.buildSSLOptions(BulkLoader.java:261)
> at org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:64)
> at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:49)
> Caused by: java.io.IOException: Error creating/initializing the SSL Context
> at
> org.apache.cassandra.security.SSLFactory.createSSLContext(SSLFactory.java:184)
> at
> org.apache.cassandra.tools.BulkLoader.buildSSLOptions(BulkLoader.java:257)
> ... 2 more
> Caused by: java.lang.IllegalStateException: SSLContext is not initialized
> at
> sun.security.ssl.SSLContextImpl.engineGetSocketFactory(SSLContextImpl.java:208)
> at javax.net.ssl.SSLContextSpi.getDefaultSocket(SSLContextSpi.java:158)
> at
> javax.net.ssl.SSLContextSpi.engineGetDefaultSSLParameters(SSLContextSpi.java:184)
> at javax.net.ssl.SSLContext.getDefaultSSLParameters(SSLContext.java:435)
> at
> org.apache.cassandra.security.SSLFactory.createSSLContext(SSLFactory.java:178)
> ... 3 more
> {quote}
> I believe this is because of a change to SSLFactory for CASSANDRA-13325 here:
> [https://github.com/apache/cassandra/commit/919a8964a83511d96766c3e53ba603e77bca626c#diff-0d569398cfd58566fc56bfb80c971a72afe3f392addc2df731a0b44baf29019eR177-R178]
>
> I think the solution is to call {{ctx.init()}} before trying to call
> {{ctx.getDefaultSSLParameters()}}, essentialy swapping the two lines in the
> link above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
