Hi list, there is a question in CASSANDRA-19556 we would like to have more feedback on in order to move forward.
CASSANDRA-19556 wants to introduce two guardrails. One for forbidding / allowing DCL statements - (Authentication|Authorization)Statement - and another one for DDL statements (all schema modifications). However, there is already a guardrail implemented by CASSANDRA-17495 which prevents only modifications of schema on a table level so CASSANDRA-19556 might be viewed as a superset of CASSANDRA-17495. I am not sure why we stopped with tables only in CASSANDRA-17495, this might be extended to keyspaces too, any schema modification really. I think we have three options here: 1) drop CASSANDRA-17495 and implement CASSANDRA-19556 which would cover _all_ schema modifications, not just table-related ones 2) keep CASSANDRA-17495 and implement CASSANDRA-19556 as is currently proposed - that means that we would be able to forbid all schema modifications by CASSANDRA-19556 but once schema modifications are allowed, we might further forbid table modifications as implemented by CASSANDRA-17495. 3) keep CASSANDRA-17495 but change the implementation of CASSANDRA-19556 in such a way that it would be more granular. What I mean by the granularity is that we would have separate guardrail for keyspace, for example. 2) is the least impactful approach but what I do not like is that, basically, one guardrail (CASSANDRA-19556) would shadow CASSANDRA-17495. For example, if the first one is disabled but the second one is enabled, we can modify keyspaces but we can not modify tables. When the first one is enabled, we can not modify tables even 17495 is not disabled which I find counterintuitive. The pros of 3) would be that it would be more granular, indeed, but, is that even necessary? There are a lot of ddl statements, creation of triggers, views, indices, functions, aggregates ... How are we going to categorize it? Do we want to have a guardrail per logical schema component? Is that not an overkill? Can you come up with a scenario when an operator wants to disable keyspace modifications but they would enable table modifications? Or disabling just index, materialized view or function creations / modifications but e.g keyspace modifications would be possible? Is it not easier to have one guardrail for all schema modifications? Given that CASSANDRA-17495 was not released in any GA (just in 5.0-alpha1), I think that the option 1) is still viable - we would drop CASSANDRA-17495 and we would have CASSANDRA-19556 instead of that which would act as a global on/off on all schema modifications however given that we go into beta2 I am not sure if it is not just too late. Thank you for your opinions in advance. Regards
