Re: [VOTE] CEP-42: Constraints Framework

+1 > On Jul 1, 2024, at 8:34 PM, Doug Rohrer wrote: > > +1 (nb) - Thanks for all of the suggestions and Bernardo for wrangling the > CEP into shape! > > Doug > >> On Jul 1, 2024, at 3:06 PM, Dinesh Joshi wrote: >> >> +1 >> >> On Mon, Jul 1, 2024 at 11:58 AM Ariel Weisberg >

Re: [VOTE] CEP-40: Data Transfer Using Cassandra Sidecar for Live Migrating Instances

+1 > On Jun 27, 2024, at 3:03 PM, Josh McKenzie wrote: > > +1 > > On Thu, Jun 27, 2024, at 12:40 AM, Abhijeet Dubey wrote: >> +1 >> >> On Thu, Jun 27, 2024 at 1:47 AM Francisco Guerrero > > wrote: >> +1 >> >> On 2024/06/21 15:13:31 Venkata Hari Krishna Nukala wrote

Re: [VOTE] CEP-24 Password validation / generation

+1 > On Jun 17, 2024, at 4:24 PM, Dinesh Joshi wrote: > > +1. > > I have some minor feedback on how the configuration of different character > classes works but that can be handled during the patch review. > > On Mon, Jun 17, 2024 at 2:32 AM Štefan Miklošovič

Re: [Discuss] CEP-24 Password validation and generation

Agree on your point - password rotation logic is business specific and database doesn’t have to worry about that. > On Jun 7, 2024, at 6:58 PM, Štefan Miklošovič > wrote: > > Hi Shailaja, > > thanks for taking a look at this. > > That was indeed just an example we can change. It was more a

Re: [Discuss] CEP-24 Password validation and generation

Hi Stefan, Thanks for the CEP, sounds great. Regarding If we were about to make this even harder to bypass, we may say that password can be changed once per day, for example (anytime for a superuser). Since we have "created" column which is of type timeuuid, we would check this table and see i

Re: [DISCUSS] Stream Pipelines on hot paths

I would like to vote for banning streams in all non-test code. It may not be easy for new contributors to distinguish between hot path and non-hot path. So would be great if we can simply block them in non-test code and update codestyle to detect the usage. > On Jun 4, 2024, at 6:26 PM, Josh M

Re: [DISCUSS] New CQL command/option for listing roles with superuser privileges

Thanks everyone for comments. I would like to close this discussion if there are no further comments and continue with the PR for code changes. I prefer ‘LIST SUPERUSERS’ cql command, please let me know if you prefer different command/option. > On Mar 1, 2024, at 12:44 PM, Sam Tunnicliffe wr

Re: [DISCUSS] New CQL command/option for listing roles with superuser privileges

- Forgot to mention, is_superuser of roles table cannot be altered as it is just showing what is persisted in the table. We can think about changing super column of LIST ROLES command instead. - Regarding change of the underlying state while we retrieve superusers info, I believe we do not need

Re: [DISCUSS] New CQL command/option for listing roles with superuser privileges

- In the example you listed below, role2 doesn’t lose superuser status because it was created as a superuser (based on the point 2). The scenario you mentioned can happen if role2 was initially not created as a superuser. When we create a role as a superuser, we persist that info in roles table,

Re: [DISCUSS] New CQL command/option for listing roles with superuser privileges

Don’t know why is_superuser was not set to true for acquired superusers. Now if we change it, may break existing tools/scripts/understanding of customers, so do we want to update current understanding of is_superuser column or introduce a new column or option instead? > On Feb 29, 2024, at 11:

Re: [DISCUSS] New CQL command/option for listing roles with superuser privileges

Hi Maxwell, Currently system_auth.roles table doesn’t have acquired superuser info available in columns to filter on it. Below is the system_auth.roles table for the example I have listed in the previous email. If you notice, though role1 and role11 acquired superuser status through grants, is_

Re: [Discuss] CQLSH should left-align numbers, right-align text (CASSANDRA-19150)

Hi Brad, While I prefer the indentation style that Postgres following for better readability of text, if we are changing it, this may break existing scripts of users/operators if tightly coupled with the current format/spaces etc (Ideally shouldn’t be, but as Cassandra being used all over the w

Re: [VOTE] CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics

+1 > On 5 May 2023, at 11:44 am, Sam Tunnicliffe wrote: > > +1 > >> On 4 May 2023, at 17:46, Doug Rohrer wrote: >> >> Hello all, >> >> I’d like to put CEP-28 to a vote. >> >> Proposal: >> >> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-28%3A+Reading+and+Writing+Cassandra+Data