Re: [DISCUSS] CEP-42: Constraints Framework

2024-06-07 Thread Štefan Miklošovič
How I see it is that in 5.1 there will be TCM for the very first time and I do not think that config in TCM would make it into 5.1 based on what Sam talks about (need for some stability etc), that makes total sense to me. TCM is quite a big feature to deliver on its own and putting even way more

Re: [DISCUSS] CEP-42: Constraints Framework

2024-06-07 Thread Sam Tunnicliffe
We've been working on a draft CEP for migrating config from yaml to cluster metadata but have been a bit short of time recently, I'll try to get something out for discussion as soon as possible. A little delay isn't such a bad thing IMO, as we're still ironing out the kinks in the TCM

Re: [DISCUSS] CEP-42: Constraints Framework

2024-06-07 Thread Štefan Miklošovič
Yes, all configuration should be transactional (configuration which makes sense to require to be the same cluster-wide). Guardrails in TCM are just a subset of this problem. When I started to do CEP-24 I started with guardrails in TCM but then I realized it leads to more general "all config in

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

2024-06-07 Thread Štefan Miklošovič
Hi Shailaja, thanks for taking a look at this. That was indeed just an example we can change. It was more about showing what might be possible in the future, nothing is set in stone yet, as the last sentence "this is not the part of the initial implementation" explains. When it comes to these

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

2024-06-07 Thread Venkata Hari Krishna Nukala
Summarizing the discussion happened so far *Data copy using rsync vs SideCar* Data copy via rsync is an incomplete solution and has to be executed outside of the Cassandra ecosystem. Data copy via Sidecar is valuable for Cassandra to have an ecosystem-native approach outside the streaming path

Re: [DISCUSS] Stream Pipelines on hot paths

2024-06-07 Thread Jordan West
Agreed Aleksey. I wouldn’t be opposed to more nuanced use but the burden that adds seems impractical. A simple rule is easier. Jordan On Fri, Jun 7, 2024 at 05:59 Aleksey Yeshchenko wrote: > It am okay with its use off hot paths in principle, and I’ve done it > myself. > > But as others have

Re: [DISCUSS] CEP-42: Constraints Framework

2024-06-07 Thread Doug Rohrer
There’s a difference between the two though. Constraints are part of the table schema, and (independent of the interaction with Guardrails), have no dependency on yaml files being perfectly in sync across the cluster. Therefore, the feature (Constraints) on its own doesn’t depend on

Re: [DISCUSS] CEP-42: Constraints Framework

2024-06-07 Thread Bernardo Botella
My concern about mentioning other potential constraints to be implemented in the future on the CEP is it may derail the conversation from the set of initial ones I want to propose, which are size and value constraints. There is definitely a lot of other potential constraints that we could

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

2024-06-07 Thread shailajakoppu
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

Re: [DISCUSS] Stream Pipelines on hot paths

2024-06-07 Thread Aleksey Yeshchenko
It am okay with its use off hot paths in principle, and I’ve done it myself. But as others have mentioned, it’s not obvious to every contributor what is and isn’t a hot path. Also, the codebase is a living, shifting thing: a cold path today can suddenly become hot tomorrow - it’s not uncommon.

Re: [DISCUSS] Stream Pipelines on hot paths

2024-06-07 Thread Berenguer Blasi
I think the value of this conversation is surfacing the problem with streams and raising awareness. If you use them in some test that sounds good to me. Same happens with some loops that trigger iterators that might inadvertently hydrate lots of unnecessary stuff into memory etc. Keeping

Re: [DISCUSS] Stream Pipelines on hot paths

2024-06-07 Thread Štefan Miklošovič
I think it makes sense to use streams to make the life easier for a dev when constructing some log messages or something like that in clearly not hot paths. Nothing wrong with that ... Collectors.joining(", ") and that kind of stuff. I do not think that doing this aggressively and "orthodoxly" is

Re: [DISCUSS] Stream Pipelines on hot paths

2024-06-07 Thread Benedict
I have to admit I didn’t expect when I raised this to be in a minority ok with *some* stream use :)Works for me though, definitely preferable to the status quo.On 7 Jun 2024, at 10:10, Aleksey Yeshchenko wrote:Ban in all new non-test code seems like the most pragmatic approach to me as well.On 7

Re: [DISCUSS] Stream Pipelines on hot paths

2024-06-07 Thread Aleksey Yeshchenko
Ban in all new non-test code seems like the most pragmatic approach to me as well. > On 7 Jun 2024, at 06:32, Jordan West wrote: > > Similarly in the "don't use them in the main project but am ok with tests" > camp > > On Thu, Jun 6, 2024 at 4:46 AM Štefan Miklošovič

Re: [DISCUSS] CEP-42: Constraints Framework

2024-06-07 Thread Dinesh Joshi
On Thu, Jun 6, 2024 at 1:50 PM Bernardo Botella < conta...@bernardobotella.com> wrote: > I will update the CEP being specific with the two specific Constraint > types I will be adding, which are size and value (the ones shown in the > example). > Could you identify constraints for the most