[
https://issues.apache.org/jira/browse/CASSANDRA-18357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18357:
------------------------------------------
Description:
If there is a custom implementation of topology strategy, that strategy can
accept more options, not only "class" and "replication factors for datacenters".
I can have a replication strategy like this:
{code}
CREATE KEYSPACE ks WITH replication = {'class': 'CustomTopologyStrategy',
'datacenter1': '1', 'some_other_option': 'myoptionvalue'};
{code}
There is nothing which prevents users to put whatever options they want into a
strategy as it is a map. Currently, we treat all options except "class" as
names of datacenters and the current code is pretty much opinionated about that
(KeyspaceParams class).
nodetool describecluster command prints this:
{code}
Keyspaces:
system_schema -> Replication class: LocalStrategy {}
system -> Replication class: LocalStrategy {}
test -> Replication class: SimpleStrategy {replication_factor=1}
system_auth -> Replication class: SimpleStrategy {replication_factor=1}
system_distributed -> Replication class: SimpleStrategy
{replication_factor=3}
system_traces -> Replication class: SimpleStrategy
{replication_factor=2}
testks -> Replication class: CustomTopologyStrategy {datacenter1=1}
{code}
But it should print:
{code}
testks -> Replication class: CustomTopologyStrategy {datacenter1=1,
some_other_option=myoptionvalue}
{code}
Another option would be to modify CQL like this:
{code}
CREATE KEYSPACE ks WITH replication = {'class': 'CustomTopologyStrategy',
'datacenter1': '1'} AND options = {'some_other_option': 'myoptionvalue'}
{code}
I would start with simply adding other options to that output. We can still
modify it later to have "AND options ..." in CQL, it is OK to expand CQL like
that if we decide. This ticket does not prevent that.
was:
If there is a custom implementation of topology strategy, that strategy can
accept more options, not only "class" and "replication factors for datacenters".
I can have a replication strategy like this:
{code}
CREATE KEYSPACE ks WITH replication = {'class': 'CustomTopologyStrategy',
'datacenter1': '1', 'some_other_option': 'myoptionvalue'};
{code}
There is nothing which prevents users to put whatever options they want into a
strategy as it is a map. Currently, we treat all options except "class" as
names of datacenters and the current code is pretty much opinionated about that
(KeyspaceParams class).
nodetool describecluster command prints this:
{code}
Keyspaces:
system_schema -> Replication class: LocalStrategy {}
system -> Replication class: LocalStrategy {}
test -> Replication class: SimpleStrategy {replication_factor=1}
system_auth -> Replication class: SimpleStrategy {replication_factor=1}
system_distributed -> Replication class: SimpleStrategy
{replication_factor=3}
system_traces -> Replication class: SimpleStrategy
{replication_factor=2}
testks -> Replication class: CustomTopologyStrategy {datacenter1=1}
{code}
But it should print:
{code}
testks -> Replication class: CustomTopologyStrategy {datacenter1=1,
some_other_option=myoptionvalue}
{code}
> Make nodetool describecluster print all configuration parameters of topology
> strategies
> ---------------------------------------------------------------------------------------
>
> Key: CASSANDRA-18357
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18357
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
> Priority: Normal
>
> If there is a custom implementation of topology strategy, that strategy can
> accept more options, not only "class" and "replication factors for
> datacenters".
> I can have a replication strategy like this:
> {code}
> CREATE KEYSPACE ks WITH replication = {'class': 'CustomTopologyStrategy',
> 'datacenter1': '1', 'some_other_option': 'myoptionvalue'};
> {code}
> There is nothing which prevents users to put whatever options they want into
> a strategy as it is a map. Currently, we treat all options except "class" as
> names of datacenters and the current code is pretty much opinionated about
> that (KeyspaceParams class).
> nodetool describecluster command prints this:
> {code}
> Keyspaces:
> system_schema -> Replication class: LocalStrategy {}
> system -> Replication class: LocalStrategy {}
> test -> Replication class: SimpleStrategy {replication_factor=1}
> system_auth -> Replication class: SimpleStrategy
> {replication_factor=1}
> system_distributed -> Replication class: SimpleStrategy
> {replication_factor=3}
> system_traces -> Replication class: SimpleStrategy
> {replication_factor=2}
> testks -> Replication class: CustomTopologyStrategy {datacenter1=1}
> {code}
> But it should print:
> {code}
> testks -> Replication class: CustomTopologyStrategy {datacenter1=1,
> some_other_option=myoptionvalue}
> {code}
> Another option would be to modify CQL like this:
> {code}
> CREATE KEYSPACE ks WITH replication = {'class': 'CustomTopologyStrategy',
> 'datacenter1': '1'} AND options = {'some_other_option': 'myoptionvalue'}
> {code}
> I would start with simply adding other options to that output. We can still
> modify it later to have "AND options ..." in CQL, it is OK to expand CQL like
> that if we decide. This ticket does not prevent that.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
