smiklosovic commented on code in PR #4393:
URL: https://github.com/apache/cassandra/pull/4393#discussion_r2383992357
##########
src/java/org/apache/cassandra/db/guardrails/Guardrails.java:
##########
@@ -143,6 +143,20 @@ public final class Guardrails implements GuardrailsMBean
state ->
CONFIG_PROVIDER.getOrCreate(state).getTablePropertiesDisallowed(),
"Table Properties");
+ /**
+ * Guardrail warning about, ignoring or rejecting the usage of certain
keyspace properties.
+ */
+ public static final Values<String> keyspaceProperties =
+ new Values<>("keyspace_properties",
+ null,
+ state ->
CONFIG_PROVIDER.getOrCreate(state).getKeyspacePropertiesWarned(),
+ state ->
CONFIG_PROVIDER.getOrCreate(state).getKeyspacePropertiesIgnored(),
+ state ->
CONFIG_PROVIDER.getOrCreate(state).getKeyspacePropertiesDisallowed()
+ .stream()
+ .filter(prop -> !"replication".equals(prop))
Review Comment:
@aparnanaik0522 this is not what we have approved, seems like this went in
after the review. I do not think this is the correct way to do it. Every single
time we execute guard method, this "stream and filter" is going to be executed
as side effect. This is not necessary. Better way would be to filter out
unsupported properties to disallow in `setKeyspacePropertiesDisallowed` method
and hence by proxy in `validateKeyspaceProperties` which is used for other
Values getter methods (getKeyspacePropertiesWarned/Ignored ...).
Another issue is - why are we doing this for "disallowed" only? If you want
to completely bypass any logic related to `replication`, as of now, you might
_ignore it_ at guardrail level. So if somebody does
create keyspace abc with replication {dc1, rf: 5}
and you put "replication" among ignored values (which is currently
possible), a keyspace like this will be created, basically.
create keyspace abc;
Is this really what we want? I do not see why we would be preventing anybody
from specifying their replication factors for their keyspaces.
cc @maedhroz
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
