[
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).
However, when I create a keyspace like this:
{code}
CREATE KEYSPACE ks WITH replication = {'class': 'CustomTopologyStrategy',
'datacenter1': '1'};
{code}
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}
The reason this is happening is that params are saved to
system_schema.keyspaces into "replication" column and if I do not specify all
parameters upon keyspace creation, they will not be persisted so describing it
via nodetool will print only that.
I want to see all options, even I have not set them explicitly in CQL CREATE
KEYSPACE ...
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. Adding of "options" is
more complicated. We would need to have another column for that in
system_schema.keyspaces and (Java) drivers would need to be accommodated too.
Too much work ...
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}
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.
> 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).
> However, when I create a keyspace like this:
> {code}
> CREATE KEYSPACE ks WITH replication = {'class': 'CustomTopologyStrategy',
> 'datacenter1': '1'};
> {code}
> 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}
> The reason this is happening is that params are saved to
> system_schema.keyspaces into "replication" column and if I do not specify all
> parameters upon keyspace creation, they will not be persisted so describing
> it via nodetool will print only that.
> I want to see all options, even I have not set them explicitly in CQL CREATE
> KEYSPACE ...
> 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. Adding of "options" is
> more complicated. We would need to have another column for that in
> system_schema.keyspaces and (Java) drivers would need to be accommodated too.
> Too much work ...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
