Thank you for changing your mind, Himanshu, and for the investigation, Francisco as well as for support, Isaac.
UUIDRoleGenerator class is pretty self-contained, I do not have a problem with copying it to Sidecar and creating an endpoint for this if you would like to see it there too so users can decide if they go to use it in vanilla Cassandra, via CQL, or they will deploy Sidecar and will interact with it via HTTP. The shortcoming I see is that this will not be pluggable as the solution in Cassandra would be. I really consider this aspect of it to be out of scope while I can recognize that the default generator is already useful enough for Sidecar users to integrate with. Is this something which might be considered enough for this CEP to pass? I am really trying to meet you with your requirements half-way and all suggestions so far were reasonably integrated and acted upon. Regards On Wed, Sep 17, 2025 at 6:42 PM Jindal, Himanshu <[email protected]> wrote: > Thanks for the clarifications. After reviewing the use cases from Štefan > and others, I’m withdrawing my concerns. I see value in supporting this > feature directly in CQL, and I appreciate Francisco’s point that the syntax > changes are additive. I also want to acknowledge that we don’t yet have a > fully voted-in CEP for SQL alignment, so until then, I don’t think we > should block features on that basis. > Best, > Himanshu > > > *From: *Francisco Guerrero <[email protected]> > *Date: *Wednesday, September 17, 2025 at 9:26 AM > *To: *[email protected] <[email protected]> > *Subject: *RE: [EXTERNAL] [DISCUSS] CEP-55 Generated role names > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you can confirm the sender and know > the content is safe. > > > > I am of the opinion of having this feature in both Sidecar and Cassandra. > > Also, I was reading SQL-92 ANSI standard [1] and it does have verbiage > around > adding extensions and options. The existing grammar does not diverge > from the standard, and what Stefan is proposing is actually additive. > > Quoting the relevant portion of the standard: > > 23.3 Extensions and options > > A conforming implementation may provide additional facilities or > options not specified by this International Standard. This may im- > ply an implementation-defined extension of the list of reserved > words (<reserved word>) and thereby may prevent proper process- > ing of some programs that otherwise meet the requirements of this > International Standard. > > An implementation remains conforming even if it provides user op- > tions to process nonconforming SQL language or to process conform- > ing SQL language in a nonconforming manner. > > I understand we want to be close to the standard, but I think we really > need to define _which_ standard. Or what does it mean to be standard? > Do we follow what other databases are doing or should we say that we > aim to be standard with a specific version of the SQL ANSI standard? > > Best, > - Francisco > > [1] https://www.contrib.andrew.cmu.edu/%7Eshadow/sql/sql1992.txt > > > On 2025/09/17 15:22:20 Isaac Reath wrote: > > 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 <[email protected]> > 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 <[email protected]> > > > 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č < > [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. > > > > > > > > > > > >
