I share Jaydeep’s opinion that SQL support is a great strategic goal, but should not block meaningful improvements that can make life easier for operators (and I think CEP-55 clearly does that).
With regard to a Sidecar implementation, it would be great to see this added to Sidecar alongside the proposed CQL changes to provide this type of functionality to existing Cassandra versions without having to backport this feature. Whether that belongs within CEP-55 or as a separate Jira in the Sidecar project, I’d lean toward keeping it separate to avoid creeping CEP-55’s scope. On Wed, Sep 17, 2025 at 9:34 AM Josh McKenzie <jmcken...@apache.org> wrote: > 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. > > I strongly disagree. People have their own control planes because we > didn't have a feature-rich sidecar in the past. As we add more > functionality to it (see: CDC, recent work on lifecycle management, etc), > and when / if we document including it as a library dependency to existing > control planes as a viable integration path, more environments would have > this functionality. > > People aren't going to deploy sidecar just because they want to delegate > this one task to it. They're going to deploy sidecar because of the > totality of the different features it offers, hypothetically this being one > of them. > > Also - :whynotboth: > > On Wed, Sep 17, 2025, at 5:16 AM, Štefan Miklošovič wrote: > > 1. While I can in general see where that goes I think that you are being > too orthodox in this area. I think it would be appropriate if you applied > this reasoning more sensitively and situationally. Nobody is going to rip > our eyes off if we make things more comfortable for them. The last thing I > expect is that people would not choose to use Cassandra because we dared to > apply completely innocent syntactic sugar in CQL to simplify their life. It > would be something else if this was something a user just can not ignore if > they choose to. It would be also different if we tried to consolidate CQL > with SQL on the most commonly used "fronts" but I just think that applying > this logic too rigidly is actually counter-productive. > > What does even your talk have in common with how people want to use a > cluster? Do you have some ultimate say in that? Well I do not entirely > agree with your talk then. Now what? > > There are already people (Dinesh, Jaydeep, Francisco, Yifan) who consider > this useful. What position do you talk from exactly so that you have the > ultimate say on how things are going to look like here? Patrick comes, puts > big -1 on that without considering how others might use it, proposes the > workaround which I consider to be actually inferior and is not willing to > accept that other people still find it useful. I do not think that is a > healthy way to do this. > > 2. See my response to Joel about this. > > 3. there are no substantial changes. As already said this is completely > optional to use. It is built on top of guardrails code which is in prod > quite a while as well. > > On Wed, Sep 17, 2025 at 2:11 AM Patrick McFadin <pmcfa...@gmail.com> > wrote: > > 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č <smikloso...@apache.org> > 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 <pmcfa...@gmail.com> > 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 <m...@apache.org> 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. > > >
