[
https://issues.apache.org/jira/browse/CASSANDRA-20779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maulin Vasavada updated CASSANDRA-20779:
----------------------------------------
Description:
The current
[documentation|https://cassandra.apache.org/doc/4.0/cassandra/tools/sstable/sstableloader.html]
for the SSTableLoader about configuring SSL can be better as discussed in
CASSANDRA-20484 ticket. Below are some challenges with the current
documentation-
# The SSTableLoader uses/piggybacks on the two existing encryption options -
meant for used by the server side config- `client_encryption_options` and
`server_encryption_options`. It relies on `client_encryption_options` to gather
cluster level metadata information and uses `server_encryption_options` for
connecting to the `storage port` on the server side for the bulk loading.
# The client encryption options specified via the command line arguments
mentions `Client SSL:` prefix to describe them which is confusing because
generally the 'client' in the client/server system is a terminology used by the
server to refer to any application connecting to it. As the SSTableLoader
itself is a client application talking to the Cassandra servers/nodes, it is
confusing to have "Client SSL" configs for itself.
# Also it could be worth to clarify the purpose of the each configuration
options to avoid the confusion mentioned in the 1st point.
As mentioned in the CASSANDRA-20484 ticket, while the overloading of the
`client_encryption_options` usage in SSTableLoader can be confusing, it can be
considered a reasonable compromise to avoid introducing specific SSL
configurations in the cassandra.yaml just for the SSTableLoader. Hence this
ticket is not seeking to make code changes to introduce any new configurations.
However, in the future it could be worth to see if we can make it really
straightforward by just having a single encryption options configuration to be
used by the SSTableLoader.
was:
The current
[documentation|https://cassandra.apache.org/doc/4.0/cassandra/tools/sstable/sstableloader.html]
for the SSTableLoader about configuring SSL can be better as discussed in
CASSANDRA-20484 ticket. Below are some challenges with the current
documentation-
# The SSTableLoader uses/piggybacks on the two existing encryption options -
meant for used by the server side config- `client_encryption_options` and
`server_encryption_options`. It relies on `client_encryption_options` for
gather cluster level metadata information and uses `server_encryption_options`
for connecting to the `storage port` on the server side for the bulk loading.
# The client encryption options specified via the command line arguments
mentions `Client SSL:` prefix to describe them which is confusing because
generally the 'client' in the client/server system is a terminology used by the
server to refer to any application connecting to it. As the SSTableLoader
itself is a client application talking to the Cassandra servers/nodes, it is
confusing to have "Client SSL" configs for itself.
# Also it could be worth to clarify the purpose of the each configuration
options to avoid the confusion mentioned in the 1st point.
As mentioned in the CASSANDRA-20484 ticket, while the overloading of the
`client_encryption_options` usage in SSTableLoader can be confusing, it can be
considered a reasonable compromise to avoid introducing specific SSL
configurations in the cassandra.yaml just for the SSTableLoader. Hence this
ticket is not seeking to make code changes to introduce any new configurations.
However, in the future it could be worth to see if we can make it really
straightforward by just having a single encryption options configuration to be
used by the SSTableLoader.
> Improve documentation for SSTableLoader documentation for SSL configuration
> ---------------------------------------------------------------------------
>
> Key: CASSANDRA-20779
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20779
> Project: Apache Cassandra
> Issue Type: Improvement
> Reporter: Maulin Vasavada
> Assignee: Maulin Vasavada
> Priority: Normal
>
> The current
> [documentation|https://cassandra.apache.org/doc/4.0/cassandra/tools/sstable/sstableloader.html]
> for the SSTableLoader about configuring SSL can be better as discussed in
> CASSANDRA-20484 ticket. Below are some challenges with the current
> documentation-
> # The SSTableLoader uses/piggybacks on the two existing encryption options -
> meant for used by the server side config- `client_encryption_options` and
> `server_encryption_options`. It relies on `client_encryption_options` to
> gather cluster level metadata information and uses
> `server_encryption_options` for connecting to the `storage port` on the
> server side for the bulk loading.
> # The client encryption options specified via the command line arguments
> mentions `Client SSL:` prefix to describe them which is confusing because
> generally the 'client' in the client/server system is a terminology used by
> the server to refer to any application connecting to it. As the SSTableLoader
> itself is a client application talking to the Cassandra servers/nodes, it is
> confusing to have "Client SSL" configs for itself.
> # Also it could be worth to clarify the purpose of the each configuration
> options to avoid the confusion mentioned in the 1st point.
>
> As mentioned in the CASSANDRA-20484 ticket, while the overloading of the
> `client_encryption_options` usage in SSTableLoader can be confusing, it can
> be considered a reasonable compromise to avoid introducing specific SSL
> configurations in the cassandra.yaml just for the SSTableLoader. Hence this
> ticket is not seeking to make code changes to introduce any new
> configurations. However, in the future it could be worth to see if we can
> make it really straightforward by just having a single encryption options
> configuration to be used by the SSTableLoader.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
