1. No. CQL did not "hurt me" and I'm not advocating we preserve CQL for posterity. Quite the opposite. I know you weren't at CoC, but my presentation was about how we move forward as a project. It will be available soon as a recording, but you can view the slides here: https://drive.google.com/file/d/1JCaWwLyniR-dNcsgdMVOLT2MfBcvvtTh/view?usp=sharing My recommendation to everyone was a move to supporting standard SQL syntax and freeze new CQL syntax. Supporting a similar-but-different SQL dialect in CQL is a liability we can easily fix. Formal proposal coming soon.
2. Sidecar is what we have chosen to adopt in the project as the control plane service because it's what makes sense for the future. Saying that nobody uses Sidecar, therefore, we shouldn't encourage people to use Sidecar will not help us drive adoption. 3. Let me channel my inner CISO. The RBAC code has been well vetted and in production for a long time. By making substantial changes to that codebase, we now reset the clock on well-tested and well-understood critical path code. aka More surface area. On Tue, Sep 16, 2025 at 3:16 PM Štefan Miklošovič <[email protected]> wrote: > Oh crap, what a feedback! If nothing else this shows a lesson to everybody > that the most sure way to have a fast feedback if you are tired of waiting > or impatient so you can move quickly is to just propose your ideas, then > boldly proclaim you go to do something and the universe will mysteriously > take care of finding out somebody who will reject it. Because people are > not always interested in agreeing. A lot of times, they take action only in > case they don't and are put in front of it. So don't be afraid to take some > flak as soon as possible! > > > > On Tue, Sep 16, 2025 at 9:05 PM Patrick McFadin <[email protected]> > wrote: > >> Thanks Mick, I'm just digging into this more after a long week of travel. >> >> 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. >> > > Why should we keep it "as is"? Genuinely asking. Why? Where is this need > for conserving stuff coming from? Is this what we are doing here? Adding as > little as possible? I think we are stifling innovation unnecessarily. There > was the same discussion about constraints and CHECK NOT NULL / NOT NULL > where we were trying to follow "the Holy Postgres Grail". I just don't get > it. Are we not obsessed with that at this point? Literally nobody cares if > there will be CREATE GENERATED ROLE. Nobody. Cares. So I do not take this > point of yours as valid without some strong backing from your side. > > >> - 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. >> > > Well the problem I see in putting this to Sidecar is that this would be > only possible to do via HTTP(S). Not everybody is interested in it. Hardly. > Zero interest. Sidecar is 0.2.0 at this point. I think that realistically > speaking I am not far from the truth at all if I say that there is > practically nobody who is using 0.2.0 in production. 0.2.0. I do not count > exceptions as early adopters or Analytics. > > Putting this to Sidecar almost guarantees nobody is going to use this > particular functionality. People have their own control planes, their own > way of generating this stuff and they are not going to deploy Sidecar just > because they want to delegate this task to it. Come on. I think that it > would, paradoxically, create more problems for them. Not less. So again, I > do not take this point as something which is solving anything. This will > have 0 users when put in Sidecar. I think it would be better if we just > flat out refuse this instead of putting that to Sidecar. It is even worse > imho. > > Another problem with Sidecar I see is that the current implementation is > pluggable. How do you want to make this pluggable in Sidecar? Pluggable > how? People might have their own opinion on how role names should be > generated. That is why you can just code your own generator / validator, > put it on the class path and be done with it. How are you supposed to > "patch Sidecar"? You create a custom implementation, then you put it on the > class path of Sidecar? Is this even supported? I think that you have > proposed it with a good will but I don't think that would fly. > > >> Why? >> - End users will have it faster since it will work with any version of >> Cassandra supporting the CREATE syntax. (No having to backport either) >> - Keeps control plane actions optional and separated. Not an attack >> surface inside core Cassandra >> > > Thirdly, what _attack surface_? I think you are pretty aware of the fact > that this feature is by default turned off. If you have an organisation > deploying hundreds of clusters and for each they have to figure out some > role name for a user which is going to use it, how is this going to be > abused concretely? There are dedicated accounts for CQL management, > creation of a role is tied to some workflow etc. What is attacked exactly > and how? Concrete examples please. > > Dineshi had the concern that "what if we just have a script which will > generate roles repeatedly nonstop?" How is this different from having a > script which would generate roles itself instead of Cassandra and it would > execute that? What's the difference really? If you want to abuse it you > will. There is no protection against that unless we put some rate limiting > in front of it - which I do not have a problem to address in follow-up work > as already explained. > > >> - We keep the syntax of CQL more generic and less one-off. >> > > I don't think this is relevant, really. I think we should abandon this > mindset. At this point, to make the point, I suspect that CQL had to "hurt > you" somehow :) > > Regards > > >> - k8s/Cloud native friendly with separation of control plane/data plane. >> >> Patrick >> >> >> On Tue, Sep 16, 2025 at 7:31 AM Mick <[email protected]> wrote: >> >>> >>> >>> >>> > I think enough time passed for everybody to participate in the >>> discussion so I would just move on and start the voting thread soon. >>> >>> >>> >>> Can we give CEP discussions longer than ~one week, please. >>> >>> Folk are easily away/offline for a whole week. Take for example many >>> who were at Community over Code and may still be catching up on their >>> inbox, thinking dev@ is a less urgent folder. >>> >>> I haven't look at how fast the other CEP discuss threads have turned >>> around, I apologise if I'm only singling one out, my concern applies >>> generally. >>> >>>
