Re: [DISCUSS] Adding dependency on agrona

[Branimir Lambov]

The usage in the trie memtable is only for volatile access to buffers. In
this case I chose the library instead of reimplementing the functionality
(e.g. as methods in `ByteBufferUtil`) because the relevant interface makes
sense and the library is a good quality one that contains a range of other
utilities that can be very useful to Cassandra.

In other words, I personally would welcome opening Cassandra up to using
other parts of Agrona, and am asking if the community shares this sentiment.


Regards,
Branimir

On Wed, Sep 21, 2022 at 9:15 PM Derek Chen-Becker 
wrote:

> Agrona looks like it has quite a bit more than just buffers, so if we add
> this as a dependency for the new memtable, would it potentially open up use
> of other parts of Agrona (wittingly or not)? Unless I misunderstood, wasn't
> part of the new memtable implementation an interface to allow this to be
> pluggable? Could we avoid bringing it in as a full dependency for Cassandra
> if the trie memtable were packaged separately as a plugin instead of being
> included directly?
>
> Cheers,
>
> Derek
>
> On Wed, Sep 21, 2022 at 6:41 AM Benedict  wrote:
>
>> In principle no, it’s a high quality library. But it might help to
>> briefly outline what it’s used for. I assume it is instead of ByteBuffer?
>> In which case it could maybe be worthwhile discussing as a project how we
>> foresee interaction with existing buffer machinery, and maybe how we expect
>> our buffer use to evolve on the project, as we already have several buffers.
>>
>> That said, I anticipate our buffer use changing significantly with the
>> introduction of value types and native memory improvements coming in future
>> Java releases, so my personal inclination is just to accept the dependency.
>>
>> On 21 Sep 2022, at 13:29, Branimir Lambov  wrote:
>>
>> 
>> Hi everyone,
>>
>> CASSANDRA-17240 (Trie memtable implementation) introduces a dependency on
>> the agrona  library (https://github.com/real-logic/agrona).
>>
>> Does anyone have any objections to adding this dependency?
>>
>> Regards,
>> Branimir
>>
>>
>
> --
> +---+
> | Derek Chen-Becker |
> | GPG Key available at https://keybase.io/dchenbecker
> 
> and   |
> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org
> 
> |
> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
> +---+
>
>

-- 
Branimir Lambov
e. branimir.lam...@datastax.com
w. www.datastax.com

Re: [VOTE] CEP-20: Dynamic Data Masking

[Andrés de la Peña]

Vote passes with eight +1s (seven binding) and no vetos.

Thanks everyone.

On Thu, 22 Sept 2022 at 20:50, Josh McKenzie  wrote:

> +1
>
> On Thu, Sep 22, 2022, at 4:28 AM, Mick Semb Wever wrote:
>
>
>
> I'd like to propose CEP-20 for approval.
>
> Proposal:
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking
> Discussion:
> https://lists.apache.org/thread/qsmxsymozymy6dy9tp5xw9gn5fhz9nt4
>
> The vote will be open for 72 hours.
> Votes by committers are considered binding.
> A vote passes if there are at least three binding +1s and no binding
> vetoes.
>
>
>
>
> +1
>
>
>

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

[Andrés de la Peña]

I think that custom, pluggable type of guardrail will be a great addition
to the framework.

The first guardrails prototype included a factory of guardrails that was
able to provide different guardrail instances depending on the specified
class and client state. That was discarded during review in favour of a
pluggable provider of guardrail configurations, so the guardrail instances
are always the same but the source of configuration can be customized. That
allows to provide different configurations for different users with minimal
hassle. Although that works for most of the guardrails, it doesn't give the
kind of flexibility than the ability to plug custom guardrail
implementations does.

I think that the proposed approach for making specific guardrail
implementations pluggable allows us to keep the simplicity of the current
approach while also giving us flexibility for particular cases like
password validation. The generic CustomGuardrail that will be added to the
framework should ease (and standardize!) validation pluggability, so I
think it can be useful in the future.

On Mon, 19 Sept 2022 at 12:27, Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:

> Hi list,
>
> together with my colleague Jackson Fleming we put together CEP-24 about
> password validation and password generation in Cassandra.
>
> https://cwiki.apache.org/confluence/x/QoueDQ
>
> We are looking forward to discuss this CEP with you in depth.
>
> The outcome of this thread would be to sort out any issues / concerns you
> have so we might eventually vote and implement that in upstream if our
> contribution is found to be useful.
>
> There is a reference implementation provided we would like to build our
> solution on top.
>
> Regards
>
> Stefan Miklosovic
>

Re: [DISCUSS] Adding dependency on agrona

[David Capwell]

+1 from me

> On Sep 23, 2022, at 1:21 AM, Branimir Lambov  
> wrote:
> 
> The usage in the trie memtable is only for volatile access to buffers. In 
> this case I chose the library instead of reimplementing the functionality 
> (e.g. as methods in `ByteBufferUtil`) because the relevant interface makes 
> sense and the library is a good quality one that contains a range of other 
> utilities that can be very useful to Cassandra.
> 
> In other words, I personally would welcome opening Cassandra up to using 
> other parts of Agrona, and am asking if the community shares this sentiment.
> 
> 
> Regards,
> Branimir
> 
> On Wed, Sep 21, 2022 at 9:15 PM Derek Chen-Becker  > wrote:
> Agrona looks like it has quite a bit more than just buffers, so if we add 
> this as a dependency for the new memtable, would it potentially open up use 
> of other parts of Agrona (wittingly or not)? Unless I misunderstood, wasn't 
> part of the new memtable implementation an interface to allow this to be 
> pluggable? Could we avoid bringing it in as a full dependency for Cassandra 
> if the trie memtable were packaged separately as a plugin instead of being 
> included directly?
> 
> Cheers,
> 
> Derek
> 
> On Wed, Sep 21, 2022 at 6:41 AM Benedict  > wrote:
> In principle no, it’s a high quality library. But it might help to briefly 
> outline what it’s used for. I assume it is instead of ByteBuffer? In which 
> case it could maybe be worthwhile discussing as a project how we foresee 
> interaction with existing buffer machinery, and maybe how we expect our 
> buffer use to evolve on the project, as we already have several buffers.
> 
> That said, I anticipate our buffer use changing significantly with the 
> introduction of value types and native memory improvements coming in future 
> Java releases, so my personal inclination is just to accept the dependency.
> 
>> On 21 Sep 2022, at 13:29, Branimir Lambov > > wrote:
>> 
>> 
>> Hi everyone,
>> 
>> CASSANDRA-17240 (Trie memtable implementation) introduces a dependency on 
>> the agrona  library (https://github.com/real-logic/agrona 
>> ).
>> 
>> Does anyone have any objections to adding this dependency?
>> 
>> Regards,
>> Branimir
> 
> 
> -- 
> +---+
> | Derek Chen-Becker |
> | GPG Key available at https://keybase.io/dchenbecker 
> 
>  and   |
> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org 
> 
>  |
> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
> +---+
> 
> 
> 
> -- 
> Branimir Lambov
> e. branimir.lam...@datastax.com 
> w. www.datastax.com 
>