On Tue, Sep 16, 2025 at 12:05 PM Patrick McFadin <[email protected]> wrote:
> > Generally, I'm -1 for adding more custom syntax. Another concern of mine > is adding control plane actions in DDL. I understand the usefulness of a > feature like this in ops. It's a great idea.. Here would be my counter > proposal: > > - Leave the CQL as is and keep "CREATE ROLE" etc as is, and avoid making > changes to core Cassandra. > - Move the generation & policy to the sidecar project. A sidecar endpoint > will generate the role name/password, enforce prefix/suffix/length > requirements, ensure uniqueness, and then return the role and password (or > a secret handle) to the caller. > Why can’t we have both? Before you point out that this would be “redundant” let me share my rationale. The Cassandra Sidecar should provide a stable API for managing different versions of Cassandra. I would introduce this feature in the Sidecar for all supported versions. This means operators can immediately use it without worrying about the underlying version of Cassandra as long as it is supported. This means the Sidecar will have to implement a similar logic for older versions of Cassandra that won’t have the feature but that’s fine as long as the operators derive value out of it. When we push this feature into Cassandra, the Sidecar just leverages that functionality instead. This gets rid of the redundancy eventually when the future supported versions get the functionality. This avoids expensive backports of such features. For those amongst the community that run multiple versions of Cassandra, the cost of backporting features in the older releases is not only invasive but also risky. The above outlined strategy allows us to derisk and focus on validating newer versions rather than backports to older versions. Dinesh
