> 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. I think this is the best solution for our end-users long term excepting how close we are to a 5.0 GA. That said, guardrails aren't exactly super invasive destabilizing new features, so if you could get this patch in before we GA'd, I'd personally support making an exception for it.
We discussed a bit on the ticket; I fall in the ambivalent space of "I like modularity, except for when it's unnecessary complexity for a use-case or flexibility that users don't need", and not being sure whether operators would need different guardrails for functionality. Especially given security and roles. On Mon, May 6, 2024, at 7:51 AM, Štefan Miklošovič wrote: > 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
