:
> > >>
> > >> +1 on config change, +1 on disabling, and so long as the comments make
> > the
> > >> limitations and risks extremely clear, I'm fine w/out the client
> > warning.
> > >>
> > >> On Mon, Jan 14, 2019 at 12
do you mean disable creation of new SASI indices, or
> disable using existing ones? I assume it's just creation of new?
>
> On Mon, Jan 14, 2019 at 11:19 AM Andrés de la Peña <
> a.penya.gar...@gmail.com>
> wrote:
>
> > Hello all,
> >
> > It is my unde
Hello all,
It is my understanding that SASI is still to be considered an
experimental/beta feature, and they apparently are not being very actively
developed. Some higlighted problems in SASI are:
- OOMs during flush, as it is described in CASSANDRA-12662
- General secondary index consistency
I agree with Paulo's proposal. I think it will give us a very desirable
homogeneity in how we deal with experimental features.
I'm +1 to warning, config property, and experimental features (SASI and MV)
disabled by default in trunk.
These are the explicit votes for now, if I'm counting right:
-
+1 (nb)
On Thu, 23 Apr 2020 at 13:09, Aleksey Yeshchenko
wrote:
> +1
>
> > On 23 Apr 2020, at 12:58, Benjamin Lerer
> wrote:
> >
> > +1 for both
> >
> >
> >
> > On Thu, Apr 23, 2020 at 3:49 AM Jordan West wrote:
> >
> >> +1 (nb) on both counts. Thanks for bringing this up!
> >>
> >> Jordan
>
+1 (nb)
On Thu, 8 Oct 2020 at 17:15, Scott Andreas wrote:
> +1nb
>
>
> From: Jordan West
> Sent: Thursday, October 8, 2020 7:40 AM
> To: dev@cassandra.apache.org
> Subject: Re: [VOTE] Release dtest-api 0.0.6
>
> +1
>
> On Thu, Oct 8, 2020 at 7:25 AM
I don't know how hard to do it would be, but I think it would be great to
have a CI job to repeatedly run a specific test, so we can check if it's
flaky. We could systematically run it for new tests, or for existing tests
related to what we are modifying.
Using this CI job to run a suspicious
+1 (non-binding)
On Wed, 15 Jul 2020 at 16:53, Jake Luciani wrote:
> +1 (binding)
>
> On Wed, Jul 15, 2020 at 11:50 AM Joshua McKenzie
> wrote:
>
> > +1 (binding)
> >
> > On Wed, Jul 15, 2020 at 3:33 AM Yuji Ito wrote:
> >
> > > +1 (non-binding)
> > >
> > > Short Jepsen tests with crash
+1 nb
On Wed, 17 Jun 2020 at 15:06, Sylvain Lebresne wrote:
> +1 (binding)
> --
> Sylvain
>
>
> On Wed, Jun 17, 2020 at 1:58 PM Benjamin Lerer <
> benjamin.le...@datastax.com>
> wrote:
>
> > +1 (binding)
> >
> > On Wed, Jun 17, 2020 at 12:49 PM Marcus Eriksson
> > wrote:
> >
> > > +1
> > >
> >
+1 (nb)
On Mon, 22 Jun 2020 at 17:15, Eric Evans wrote:
> +0
>
> On Sat, Jun 20, 2020 at 10:12 AM Joshua McKenzie
> wrote:
> >
> > Link to doc:
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> >
> > Change since previous cancelled vote:
> > "A
+1 (nb)
On Mon, 20 Jul 2020 at 12:58, João Reis wrote:
> +1 (nb)
>
> The drivers smoke test suite looks good:
>
>
> https://ci.appveyor.com/project/DataStax/cassandra-drivers-smoke-test/builds/34194004
>
> Mick Semb Wever escreveu no dia sábado, 18/07/2020 à(s)
> 00:27:
>
> > Proposing the
Congratulations everyone!
On Thu, 17 Dec 2020 at 08:02, Sylvain Lebresne wrote:
> Congratulations to all of you. Well deserved.
> --
> Sylvain
>
>
> On Thu, Dec 17, 2020 at 12:27 AM Sumanth Pasupuleti <
> sumanth.pasupuleti...@gmail.com> wrote:
>
> > Hearty congratulations everyone!!
> >
> > On
+1 (nb)
On Sat, 31 Oct 2020 at 09:20, Mick Semb Wever wrote:
> >
> >
> > The vote will be open for 72 hours (longer if needed). Everyone who
> > has tested the build is invited to vote. Votes by PMC members are
> > considered binding. A vote passes if there are at least three binding
> > +1s
+1 (nb)
On Sat, 31 Oct 2020 at 09:17, Mick Semb Wever wrote:
> > The vote will be open for 72 hours (longer if needed). Everyone who
> > has tested the build is invited to vote. Votes by PMC members are
> > considered binding. A vote passes if there are at least three binding
> > +1s and no
+1 (nb)
On Sat, 31 Oct 2020 at 09:20, Mick Semb Wever wrote:
> +1 (binding)
>
>
> Test Results: https://ci-cassandra.apache.org/job/Cassandra-3.11/37/
>
> Checked signatures, checksums, source build, and artefacts install and run.
>
> Remaining issues:
> - lib/ directory (binary files)
+1 (nb)
On Sat, 31 Oct 2020 at 09:18, Mick Semb Wever wrote:
> > The vote will be open for 72 hours (longer if needed). Everyone who
> > has tested the build is invited to vote. Votes by PMC members are
> > considered binding. A vote passes if there are at least three binding
> > +1s and no
Hi all,
Just to inform that CASSANDRA-16625 has been merged. It adds new CircleCI
jobs to run a specific test repeatedly, so we can check if it's stable.
Hopefully it can be helpful to reproduce failures when fixing a flaky test,
and to verify that a new or modified test is stable.
JUnit tests,
Congrats Caleb, well deserved! :)
On Fri, 14 May 2021 at 17:53, Paulo Motta wrote:
> Awesome, congratulations Caleb!! :)
>
> Em sex., 14 de mai. de 2021 às 13:16, Patrick McFadin
> escreveu:
>
> > YES! Love seeing this. A very much deserved congratulations Caleb!
> >
> > Patrick
> >
> > On
+1 (nb)
On Mon, 28 Jun 2021 at 21:01, Jon Meredith wrote:
> +1 (nb)
>
> On Mon, Jun 28, 2021 at 9:47 AM Yifan Cai wrote:
> >
> > +1
> >
> >
> > - Yifan
> >
> > > On Jun 28, 2021, at 8:40 AM, Ekaterina Dimitrova <
> e.dimitr...@gmail.com> wrote:
> > >
> > > +1 Thanks everyone!
> > >
> > >> On
+1nb
On Thu, 22 Apr 2021 at 09:55, Benjamin Lerer wrote:
> +1
>
> Le jeu. 22 avr. 2021 à 07:41, Yifan Cai a écrit :
>
> > +1
> >
> > On Wed, Apr 21, 2021 at 10:33 PM Berenguer Blasi <
> berenguerbl...@gmail.com
> > >
> > wrote:
> >
> > > +1
> > >
> > > On 22/4/21 5:12, Blake Eggleston wrote:
>
Congrats!
On Tue, 4 May 2021 at 05:47, Berenguer Blasi
wrote:
> Congrats Stefan!
>
> On 3/5/21 22:24, Yifan Cai wrote:
> > Congrats!
> >
> > On Mon, May 3, 2021 at 1:23 PM Paulo Motta
> wrote:
> >
> >> Congrats, Stefan! Happy to see you onboard! :)
> >>
> >> Em seg., 3 de mai. de 2021 às
Congrats Paulo!
On Tue, 9 Feb 2021 at 17:42, Sumanth Pasupuleti <
sumanth.pasupuleti...@gmail.com> wrote:
> Congratulations Paulo!
>
> On Tue, Feb 9, 2021 at 8:10 AM Jasonstack Zhao Yang <
> jasonstack.z...@gmail.com> wrote:
>
> > Congrats Paulo!
> >
> > On Wed, 10 Feb 2021 at 00:03, Ekaterina
Congratulations Berenguer! Well deserved!
On Thu, 25 Mar 2021 at 10:11, Erick Ramirez
wrote:
> Congratulations, Berenguer! Thanks for all the work you've done.
>
>
> On Thu, 25 Mar 2021 at 21:10, Benjamin Lerer wrote:
>
> > The PMC's members are pleased to announce that Berenguer Blasi has
+1 (non-binding)
On Mon, 29 Mar 2021 at 14:50, Brandon Williams wrote:
> +1
>
> On Mon, Mar 29, 2021 at 8:05 AM Mick Semb Wever wrote:
> >
> > Proposing the test build of Cassandra 4.0-rc1 for release.
> >
> > sha1: 2facbc97ea215faef1735d9a3d5697162f61bc8c
> > Git:
> >
>
-32bdc9b9f190
I think that the fourth option gives us more flexibility, because it allows
us to start any combination of tests we want while it keeps the concept of
required tests.
On Thu, 12 Aug 2021 at 17:47, Andrés de la Peña
wrote:
> Hello all,
>
> The current CircleCI configuration auto
+1
On Wed, 1 Sept 2021 at 17:37, Ekaterina Dimitrova
wrote:
> +1
>
> On Wed, 1 Sep 2021 at 12:34, Joshua McKenzie wrote:
>
> > +1
> >
> > On Wed, Sep 1, 2021 at 11:16 AM Yifan Cai wrote:
> >
> > > +1
> > >
> > >
> > > - Yifan
> > >
> > > > On Sep 1, 2021, at 7:57 AM, C. Scott Andreas
> > >
Congrats Adam, well deserved!
On Mon, 16 Aug 2021 at 17:14, Patrick McFadin wrote:
> Great to see you on the committer list Adam!
>
> On Mon, Aug 16, 2021 at 7:06 AM Jonathan Ellis wrote:
>
> > Well deserved. Congratulations!
> >
> > On Mon, Aug 16, 2021 at 5:57 AM Benjamin Lerer
> wrote:
>
+1
On Thu, 19 Aug 2021 at 18:33, Joshua McKenzie wrote:
> +1
>
> On Thu, Aug 19, 2021 at 12:19 PM bened...@apache.org
> wrote:
>
> > +1
> >
> > From: Brandon Williams
> > Date: Thursday, 19 August 2021 at 17:16
> > To: dev@cassandra.apache.org
> > Subject: Re: [VOTE] CEP-11: Pluggable
Hi all,
Just to inform that now it's possible to generate CircleCI's config.yml
from the config-2_1.yml for a specific low/mid/high resource configuration
using the new -l/-m/-h flags. For example, ".circleci/generate.sh -h" will
generate a config.yml file for high resources.
This might be
+1, thanks for the proposal.
On Thu, 9 Sept 2021 at 16:45, Brandon Williams wrote:
> +1
>
> On Thu, Sep 9, 2021 at 10:39 AM Joshua McKenzie
> wrote:
> >
> > (Taking #cassandra-dev slack chat to here)
> >
> > For context, we have a long history of an ebb and flow of flaky test
> > failures
+1 (nb)
On Tue, 13 Jul 2021 at 10:26, Mick Semb Wever wrote:
> >
> > The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
+1
On Wed, 14 Jul 2021 at 00:39, Patrick McFadin wrote:
> +1 (nb)
>
> On Tue, Jul 13, 2021 at 3:45 PM Brandon Williams wrote:
>
> > +1
> >
> > On Tue, Jul 13, 2021, 5:14 PM Mick Semb Wever wrote:
> >
> > > Proposing the test build of Cassandra 4.0.0 for release.
> > >
> > > sha1:
Hello all,
The current CircleCI configuration automatically runs the unit tests, JVM
dtests and cqhshlib tests. This is done by default for every commit or,
with some configuration, for every push.
Along the lifecycle of a ticket it is quite frequent to have multiple
commits and pushes, all
I like the latest proposal, it's simple enough to prevent inconsistencies
in usage and "committer needed" seems useful when looking for tickets to
work on.
On Mon, 2 Aug 2021 at 21:14, Ekaterina Dimitrova
wrote:
> In the meantime the new Kanban board filter for Needs Reviewer is called
>
Congratulations, Jon!
On Fri, 30 Jul 2021 at 16:07, J. D. Jordan
wrote:
> Congrats Jon!
>
> > On Jul 30, 2021, at 9:26 AM, Paulo Motta
> wrote:
> >
> > Congratulations and welcome Jon! Always exciting to see the project
> > recognizing more committers!
> >
> >> Em sex., 30 de jul. de 2021 às
v
> > > Subject: Re: Save CircleCI resources with optional test jobs
> > > I thought this discussion was still ongoing, but it looks like
> > > CASSANDRA-16882 is now committed.
> > >
> > > Could you give some context on why at least compilation is not don
then
> update them continuously, to coexist and be able to quickly switch between
> configs) I'd be more in favour of this rather than just enabling a
> build/compile step for everyone.
>
> On Wed, Oct 20, 2021 at 8:25 PM Andrés de la Peña
> wrote:
>
> > Hi all,
> >
>
This should allow to generate the config file without manually editing
files in most cases.
On Wed, 1 Sept 2021 at 19:46, Andrés de la Peña
wrote:
> Hi all,
>
> Just to inform that now it's possible to generate CircleCI's config.yml
> from the config-2_1.yml for a specific low/mid/h
the current concept of
mandatory tests.
If no one disagrees with this approach I'll commit the changes in a few
days.
On Fri, 27 Aug 2021 at 11:54, Andrés de la Peña
wrote:
> Hi,
>
> CASSANDRA-16882 has patches for any of the mentioned configurations aimed
> to save Circle
Congratulations!
On Tue, 21 Sept 2021 at 10:37, Berenguer Blasi
wrote:
> Congrats!
>
> On 21/9/21 10:55, Benjamin Lerer wrote:
> > The PMC members are pleased to announce that Aleksei Zotov has accepted
> > last Friday the invitation to become committer.
> >
> > Thanks a lot, Aleksei, for all
I think the updated CEP incorporates the feedback above, unless I'm missing
something. Are we ready to start a vote?
On Tue, 2 Nov 2021 at 15:54, Andrés de la Peña wrote:
> Under "Migrating existing cassandra.yaml warn/fail thresholds”, I recently
>> added a few things which
v 10, 2021, at 11:17 AM, Ekaterina Dimitrova <
>> e.dimitr...@gmail.com> wrote:
>> >
>> > I am personally ready to give you my vote :-)
>> >
>> > On Wed, 10 Nov 2021 at 13:09, Andrés de la Peña
>> > wrote:
>> >
>> >
+1
On Tue, 16 Nov 2021 at 08:39, Sam Tunnicliffe wrote:
> +1
>
> > On 15 Nov 2021, at 19:42, Branimir Lambov wrote:
> >
> > Hi everyone,
> >
> > I would like to start a vote on this CEP.
> >
> > Proposal:
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-17%3A+SSTable+format+API
t; On Nov 11, 2021, at 7:10 AM, Sumanth Pasupuleti <
> > sumanth.pasupuleti...@gmail.com> wrote:
> > >
> > > +1
> > >
> > > On Thu, Nov 11, 2021 at 6:10 AM Gary Dusbabek
> > wrote:
> > >
> > >> +1
> > >>
&g
Hi everyone,
I would like to start a vote on this CEP.
Proposal:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-3%3A+Guardrails
Discussion:
https://lists.apache.org/thread/7f6lntfdnkpqr7o0h2d2jlg8q7gf54w2
https://lists.apache.org/thread/0bd6fo4hdnwc8q2sq4xwvv4nqpxw10ds
The vote will
s",
> but more as general "limits", and having them only configured via yaml
> seems like a bad outcome
>
>
>
> https://issues.apache.org/jira/browse/CASSANDRA-8303
>
>
>
> On Mon, Nov 1, 2021 at 9:31 AM Andrés de la Peña
> wrote:
>
> Hi everyon
on drivers.
What I meant by "and also to the client connection when applicable" is that
some guardrails can be applied to things that are nor necessarily
associated to a client connection, such as compaction. I have tried to be
more explicit about that.
On Tue, 2 Nov 2021 at 12:53, Andrés de
Hi all,
we already have a way to confirm flakiness on circle by running the test
> repeatedly N times. Like 100 or 500. That has proven to work very well
> so far, at least for me. #collaborating #justfyi
I think it would be helpful if we always ran the repeated test jobs at
CircleCI when we
their config file with generate.sh
-hpr.
What do you think?
On Thu, 21 Oct 2021 at 14:37, Andrés de la Peña
wrote:
> The two separate workflows try to serve both types of pushes, early and
> almost ready. The separate-test j8/j11 workflows are for those who push
> early patches, or special case
Hi everyone,
I'd like to start a discussion about Guardrails proposal:
https://cwiki.apache.org/confluence/display/CASSANDRA/%28DRAFT%29+-+CEP-3%3A+Guardrails
Guardrails are an easy way to enforce system-wide soft and hard limits to
prevent anti-patterns of bad usage and in the long run make it
+1
On Fri, 23 Jul 2021 at 11:56, Sam Tunnicliffe wrote:
> +1
>
> > On 22 Jul 2021, at 23:40, Brandon Williams
> wrote:
> >
> > I am proposing the test build of Cassandra 4.0.0 for release.
> >
> > sha1: 902b4d31772eaa84f05ffdc1e4f4b7a66d5b17e6
> > Git:
>
+1
On Mon, 26 Jul 2021 at 12:46, Ekaterina Dimitrova
wrote:
> +1
>
> On Mon, 26 Jul 2021 at 5:10, Sam Tunnicliffe wrote:
>
> > +1
> >
> > > On 25 Jul 2021, at 18:40, Brandon Williams wrote:
> > >
> > > I am proposing the test build of Cassandra 3.0.25 for release.
> > >
> > > sha1:
+1
On Mon, 26 Jul 2021 at 12:46, Ekaterina Dimitrova
wrote:
> +1
>
> On Mon, 26 Jul 2021 at 5:11, Sam Tunnicliffe wrote:
>
> > +1
> >
> > > On 25 Jul 2021, at 20:06, Brandon Williams wrote:
> > >
> > > I am proposing the test build of Cassandra 3.11.11 for release.
> > >
> > > sha1:
Still +1 with the amendment
On Wed, 12 Jan 2022 at 19:57, C. Scott Andreas wrote:
> +1nb, with and without the amendment.
>
> Reason for mentioning without: I see the ability to cut a release to
> address an urgent security or data loss issue as one of the strongest
> arguments for maintaining
+1
On Tue, 11 Jan 2022 at 13:45, Joshua McKenzie wrote:
> If my understanding is correct, we run the canonical set *before* merging,
>> and the runs triggered by the cassandra CI bot include the full set
>> *after* a commit is merged.
>
> Good point. Clarified to indicate it's canonical
Last time I checked there wasn't support for vnodes on in-jvm dtests, which
seems an important limitation.
On Mon, 14 Mar 2022 at 12:24, bened...@apache.org
wrote:
> I am strongly in favour of deprecating python dtests in all cases where
> they are currently superseded by in-jvm dtests. They
+1
On Wed, 16 Mar 2022 at 11:55, Anthony Grasso
wrote:
> +1
>
> On Wed, 16 Mar 2022 at 21:58, bened...@apache.org
> wrote:
>
>> +1
>>
>>
>>
>> *From: *Erick Ramirez
>> *Date: *Tuesday, 15 March 2022 at 22:08
>> *To: *dev@cassandra.apache.org
>> *Subject: *Re: [FOR REVIEW] Blog post: An
Congrats, well deserved!
On Wed, 16 Mar 2022 at 14:01, J. D. Jordan
wrote:
> Congratulations!
>
> On Mar 16, 2022, at 8:43 AM, Ekaterina Dimitrova
> wrote:
>
>
> Great news! Well deserved! Congrats and thank you for all your support!
>
> On Wed, 16 Mar 2022 at 9:41, Paulo Motta wrote:
>
>>
+1nb
On Wed, 16 Feb 2022 at 15:57, C. Scott Andreas wrote:
> +1nb
>
> On Feb 16, 2022, at 5:59 AM, Jeremy Hanna
> wrote:
>
> +1 nb. Thanks for all of the great work on this Branimir. Excited to
> see this moving forward.
>
> On Feb 16, 2022, at 7:56 AM, J. D. Jordan
> wrote:
>
> +1 nb
>
>
Hi all,
9 people have already participated on the Build Lead rotation, now we need
a brave volunteer for the next week.
Thanks for your help,
On Wed, 2 Mar 2022 at 17:10, Ekaterina Dimitrova
wrote:
> Hi everyone,
>
> It's been a month and a half since we started the Build Lead rotation.
> 6
+1
On Mon, 24 Jan 2022 at 12:29, Brandon Williams wrote:
> +1
>
> On Thu, Jan 13, 2022 at 12:17 PM Mick Semb Wever wrote:
> >
> > Proposing the test build of in-jvm dtest API 0.0.12 for release.
> >
> > Repository:
> >
>
Last time I ported dtests during the 4.0 quality test epic there wasn't
support for virtual nodes in in-jvm dtests. We have many Python dtests
depending on vnodes that can't be totally ported if we still don't have
support for vnodes, I don't know if it's still the case.
On Wed, 26 Jan 2022 at
+1
On Thu, 7 Sept 2023 at 12:52, Jacek Lewandowski
wrote:
> Mick, is the documentation / website ok?
>
> If so, +1
>
> Best Regards,
> - - -- --- - -
> Jacek Lewandowski
>
>
> czw., 7 wrz 2023 o 12:58 Brandon Williams napisał(a):
>
>> +1
>>
>> Kind Regards,
>> Brandon
I'd add that even if we commit running CI to verify that we are not
introducing new test failures, we can always inadvertently introduce new
flakies. Those flakies can be hit long after the original commit,
for example while trying to make a release.
On Tue, 31 Oct 2023 at 17:08, Paulo Motta
+1
On Wed, 4 Oct 2023 at 05:44, Berenguer Blasi
wrote:
> +1
> On 4/10/23 4:43, Erick Ramirez wrote:
>
> +1
>
>>
I have just created CASSANDRA-18876 for this. I'll post a patch very soon.
On Wed, 20 Sept 2023 at 19:41, David Capwell wrote:
> I don’t think we can readily migrate old types away from this however,
> without breaking backwards compatibility.
>
>
> Given that java driver has a different
Hi,
Although it's not yet officially supported and it might still change in a
minor release, guardrails config is also pluggable (CEP-3). It is possible
to provide a custom implementation supplying guardrail properties different
to those defined in cassandra.yaml, so the thresholds, flags, etc.
+1 nb
On Tue, 24 May 2022 at 16:10, Benjamin Lerer wrote:
> +1
>
> Le mar. 24 mai 2022 à 16:19, Josh McKenzie a
> écrit :
>
>> +1
>>
>> On Tue, May 24, 2022, at 10:13 AM, Brandon Williams wrote:
>>
>> +1
>>
>> On Tue, May 24, 2022 at 3:39 AM Mick Semb Wever wrote:
>> >
>> > Proposing the test
Hi all,
CASSANDRA-17575 has detected that token ranges in nodetool compact are
interpreted as closed on both sides. For example, the command "nodetool
compact -st 10 -et 50" will compact the tokens in [10, 50]. This way of
interpreting token ranges is unusual since token ranges are usually
> > On Tue, Jul 26, 2022 at 8:19 AM J. D. Jordan
>> wrote:
>> >>
>> >> I like the third option, especially if it makes it consistent with
>> repair, which has supported ranges longer and I would guess most people
>> would think the compact ranges work th
+1 (nb)
On Wed, 11 May 2022 at 09:00, Sam Tunnicliffe wrote:
> +1
>
> > On 7 May 2022, at 07:39, Mick Semb Wever wrote:
> >
> > Proposing the test build of Cassandra 4.0.4 for release.
> > This is from the (take4) test artifact.
> >
> > sha1: 052125f2c6ed308f1473355dfe43470f0da44364
> > Git:
>
+1 (nb)
On Wed, 11 May 2022 at 09:00, Sam Tunnicliffe wrote:
> +1
>
> > On 7 May 2022, at 07:38, Mick Semb Wever wrote:
> >
> > Proposing the test build of Cassandra 3.11.13 for release.
> >
> > sha1: 836ab2802521a685efe84382cb48db56caf4478d
> > Git:
>
+1 (nb)
On Wed, 11 May 2022 at 08:59, Sam Tunnicliffe wrote:
> +1
>
> > On 7 May 2022, at 07:37, Mick Semb Wever wrote:
> >
> > Proposing the test build of Cassandra 3.0.27 for release.
> >
> > sha1: 205366131484967a3a8a749f1d1d841c952127e8
> > Git:
>
+1 (nb)
On Tue, 23 Aug 2022 at 06:14, Tommy Stendahl via dev <
dev@cassandra.apache.org> wrote:
> +1 nb
>
> -Original Message-
> *From*: Brandon Williams >
> *Reply-To*: dev@cassandra.apache.org
> *To*: dev
> >
> *Subject*: Re: [VOTE] Release Apache Cassandra 4.0.6
> *Date*: Mon, 22
; one version of it in the result set, even if you had a way to define
> several functions.
>
> I'm not proposing this should change, just calling it out.
>
> henrik
>
> On Fri, Aug 19, 2022 at 2:50 PM Andrés de la Peña
> wrote:
>
>> Hi everyone,
>>
>>
erns around masking primary key components. It's
>>> highly likely that certain personal data properties would be used as a
>>> partition or clustering key (ex: range query for people born within a
>>> certain timeframe). In addition to the "breaks existing" c
None of the databases mentioned on the "other databases" section of
the CEP does this kind of column renaming, so it might be a kind of exotic
behaviour. wdyt?
On Fri, 19 Aug 2022 at 19:17, Andrés de la Peña
wrote:
> > This type of feature is very useful, but it may be easier to analyz
nd output from eg Azure SQL vs Cassandra vs whatever ?
>
>
> On Aug 19, 2022, at 4:50 AM, Andrés de la Peña
> wrote:
>
>
> Hi everyone,
>
> I'd like to start a discussion about this proposal for dynamic data
> masking:
> https://cwiki.apache.org/confluence/display/CA
onger, but
> this feels like a sticking plaster that distracts from that underlying
> issue.
>
> my 0.02
>
> On Mon, Aug 22, 2022 at 12:30 AM Andrés de la Peña
> wrote:
>
>> > If the column names are the same for masked and unmasked data, it would
>>> im
ructure.
>
> I am not sure either about it's value, as that would still break any key
> or other cross-referencing.
>
> My 2cts.
> On 22/8/22 1:30, Andrés de la Peña wrote:
>
> > If the column names are the same for masked and unmasked data, it would
>> impact
>
> Is there enough support here for VIEWS to be the implementation strategy
> for displaying masking functions?
I'm not sure that views should be "the" strategy for masking functions. We
have multiple approaches here:
1) CQL functions only. Users can decide to use the masking functions on
I think I'd prefer 2), the SQL behaviour. We could also get the convenience
of 3) by adding CQL functions such as "ifNull(column, default)" or
"zeroIfNull(column)", as it's done by other dbs. So we could do things like
"UPDATE ... SET name = zeroIfNull(name) + 42".
On Wed, 31 Aug 2022 at 04:54,
If nobody has more concerns regarding the CEP I will start the vote
tomorrow.
On Wed, 31 Aug 2022 at 13:18, Andrés de la Peña
wrote:
> Is there enough support here for VIEWS to be the implementation strategy
>> for displaying masking functions?
>
>
> I'm not sure
nd should implement
> the view approach
> D) We should NOT implement the table schema approach, and should implement
> some other scheme (or not implement this feature)
>
> Where my vote is B
>
> On 7 Sep 2022, at 12:50, Andrés de la Peña wrote:
>
>
> If nobody has
g masking to schema would be
> sufficient for an initial goal? That wouldn't preclude additional
> permissions, schema integration, or perhaps just plain Views in the future.
>
> Cheers,
>
> Derek
>
> On Thu, Aug 25, 2022 at 11:12 AM Andrés de la Peña
> wrote:
>
>
ble to determine its value in one query. On the other hand masking credit
>>>> card numbers makes a lot of sense as it will complicate the life of the
>>>> person trying to have access to it and the queries needed to reach the
>>>> information will leave so
numbers makes a lot of sense as it will complicate the life of the
>>>> person trying to have access to it and the queries needed to reach the
>>>> information will leave some clear traces in the audit log.
>>>>
>>>> Dynamic Data Masking is not a magic bul
default - forbid querying on
> columns that are masked, unless the mask permits it.
>
>
> On 24 Aug 2022, at 11:06, Andrés de la Peña wrote:
>
>
> Here are the names of the feature on same databases out there, errors and
> omission excepted:
>
>- Microsoft SQL S
rting with something smaller in scope. Perhaps just
> providing the masking functions and not tying masking to schema would be
> sufficient for an initial goal? That wouldn't preclude additional
> permissions, schema integration, or perhaps just plain Views in the future.
>
> Cheers,
>
gt; Is it typical for a masking feature to make no effort to prevent
>> unmasking? I’m just struggling to see the value of this without such
>> mechanisms. Otherwise it’s just a default formatter, and we should consider
>> renaming the feature IMO
>>
>> On 23 Aug 2022, a
ture.
>
> Cheers,
>
> Derek
>
> On Thu, Aug 25, 2022 at 11:12 AM Andrés de la Peña
> wrote:
>
>> I have modified the proposal adding a new SELECT_MASKED permission. Using
>> masked columns on WHERE/IF clauses would require having SELECT and either
>> UNMASK or
te, you're saying we would need SELECT_MASKED to use it in
>> the IF clause? I worry that this proposal is increasing in complexity; I
>> would actually be OK starting with something smaller in scope. Perhaps just
>> providing the masking functions and not tying masking to schema would be
Hi everyone,
I'd like to start a discussion about this proposal for dynamic data
masking:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking
Dynamic data masking allows to obscure sensitive information without
changing the stored data. It would be based on a set
>
> 250 iterations isn't enough; I use 500 as a low water mark.
I agree that 500 iterations would be a reasonable minimum. We have seen
flaky unit tests requiring far more iterations, but that's not very common.
We could use to 500 iterations as default, and discretionary use a higher
limit in
Just to let you know that CASSANDRA-17939 has just been committed.
It changes the way the CircleCI multiplexer works, in line with the recent
changes in our release criteria:
* The default number of repeated tests iterations is 500, except for long
and upgrade tests.
* It is possible to specify
ing job naming, default config
> type, and updating documentation shortly.
>
> On Tue, Oct 18, 2022, at 12:33 PM, Andrés de la Peña wrote:
>
> Just to let you know that CASSANDRA-17939 has just been committed.
>
> It changes the way the CircleCI multiplexer works, in lin
>
> Yep - instead of having to go to circle and click, when you push your
> branch the circle hook picks it up and kicks off the top level job
> automatically. I tend to be paranoid and push a lot of incremental work
> that's not ready for CI remotely so it's not great for me, but I think
> having
>
> - Ticket for: remove -h, have -f and -p (free and paid)
+1 to this, probably there isn't anyone using -h. There are some jobs that
can't pass with the free option. Maybe we should remove them from the
workflow when the free option is used. Perhaps that could save new
contributors some
Note that the test multiplexer also searches for tests ending with "Test",
so it will also miss new or modified tests with nonstandard names. The
automatically detected tests are listed when running generate.sh, and they
are added to the repeated run jobs. That gives us another opportunity to
Hi everyone,
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
1 - 100 of 154 matches
Mail list logo
