Re: [VOTE] CEP-25: Trie-indexed SSTable format

[Andrés de la Peña]

+1

On Mon, 19 Dec 2022 at 15:11, Aleksey Yeshchenko  wrote:

> +1
>
> On 19 Dec 2022, at 13:42, Ekaterina Dimitrova 
> wrote:
>
> +1
>
> On Mon, 19 Dec 2022 at 8:30, J. D. Jordan 
> wrote:
>
>> +1 nb
>>
>> > On Dec 19, 2022, at 7:07 AM, Brandon Williams  wrote:
>> >
>> > +1
>> >
>> > Kind Regards,
>> > Brandon
>> >
>> >> On Mon, Dec 19, 2022 at 6:59 AM Branimir Lambov 
>> wrote:
>> >>
>> >> Hi everyone,
>> >>
>> >> I'd like to propose CEP-25 for approval.
>> >>
>> >> Proposal:
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-25%3A+Trie-indexed+SSTable+format
>> >> Discussion:
>> https://lists.apache.org/thread/3dpdg6dgm3rqxj96cyhn58b50g415dyh
>> >>
>> >> 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.
>> >>
>> >> Thank you,
>> >> Branimir
>>
>
>

Re: Introducing mockito-inline library among test dependencies

[Andrés de la Peña]

+1 for the same reasons.

On Wed, 11 Jan 2023 at 20:14, David Capwell  wrote:

> +1. We already use mockito.  Also that library is basically empty, its
> just defining configs for extensions (see
> https://github.com/mockito/mockito/tree/main/subprojects/inline/src/main/resources/mockito-extensions
> )
>
> On Jan 11, 2023, at 12:02 PM, Miklosovic, Stefan <
> stefan.mikloso...@netapp.com> wrote:
>
> Hi list,
>
> the test for (1) is using mockito-inline dependency for mocking static
> methods as mockito-core is not able to do that on its own. mockito-inline
> was not part of our test dependencies prior this work. I want to ask if we
> are all OK with being able to mock static methods from now on with the help
> of this library.
>
> Please tell me if we are mocking static methods already by some other (to
> me yet unknown) mean so we do not include this unnecessarily.
>
> G:A:V is org.mockito:mockito-inline:4.7.0
>
> (1) https://issues.apache.org/jira/browse/CASSANDRA-14361
>
> Thanks
>
>
>

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

[Andrés de la Peña]

I guess that depends on the type of change, and what we consider an API.

If it's a breaking change, like removing a method or property, I think we
would need a DISCUSS API thread prior to making changes. However, if the
change is an addition, like adding a new yaml property or a JMX method, I
think JIRA suffices.

As for what we consider a public API, we usually include extensible
interfaces on this. For example, we can agree that the Index interface for
secondary indexes is a public API. However, that interface exposes many
other interfaces and classes through its methods. For example, that Index
interface exposes ColumnFamillyStore, SSTableReader, ColumnMetadata,
AbstractType, PartitionUpdate, etc. Changes into those indirectly exposed
classes can easily break custom index implementations out there. Should we
consider them public APIs too, and require a DISCUSS thread for every
change on them? Should that include new methods that wouldn't break
compatibility?

On Thu, 2 Feb 2023 at 09:29, Benedict Elliott Smith 
wrote:

> Closing the loop on seeking consensus for UX/UI/API changes, I see a few
> options. Can we rank choice vote please?
>
> A - Jira suffices
> B - Post a DISCUSS API thread prior to making changes
> C - Periodically publish a list of API changes for retrospective
> consideration by the community
>
> Points raised in the discussion included: lowering the bar for
> participation and avoiding unnecessary burden to developers.
>
> I vote B (only) because I think broader participation is most important
> for these topics.
>
>
> On 7 Dec 2022, at 15:43, Mick Semb Wever  wrote:
>
> I think it makes sense to look into improving visibility of API changes,
>> so people can more easily review a summary of API changes versus reading
>> through the whole changelog (perhaps we need a summarized API change log?).
>>
>
>
> Agree Paulo.
>
> Observers should be able to see all API changes early. We can do better
> than telling downstream users/devs "you have to listen to all jira tickets"
> or "you have to watch the code and pick up changes". Watching CHANGES.txt
> or NEWS.txt or CEPs doesn't solve the need either.
>
> Observing such changes as early as possible can save a significant amount
> of effort and headache later on, and should be encouraged. If done
> correctly I can imagine it will help welcome more contributors.
>
> I can also see that we can improve at, and have a better shared
> understanding of, categorising the types of API changes:
> addition/change/deprecation/removal, signature/output/behavioural, API/SPI.
> So I can see value here for both observers and for ourselves.
>
>
>

Re: Welcome Patrick McFadin as Cassandra Committer

[Andrés de la Peña]

Congratulations, Patrick!

On Thu, 2 Feb 2023 at 19:54, Francisco Guerrero  wrote:

> Congrats, Patrick!
>
> On 2023/02/02 19:52:35 Jean-Armel Luce wrote:
> > Congrats, Patrick
> >
> > Le jeu. 2 févr. 2023 à 20:46, David Capwell  a
> écrit :
> >
> > > Congrats and welcome! =)
> > >
> > > On Feb 2, 2023, at 10:53 AM, J. D. Jordan 
> > > wrote:
> > >
> > > Congrats!
> > >
> > > On Feb 2, 2023, at 12:47 PM, Christopher Bradford <
> bradfor...@gmail.com>
> > > wrote:
> > >
> > > 
> > > Congrats Patrick! Well done.
> > >
> > > On Thu, Feb 2, 2023 at 10:44 AM Aaron Ploetz 
> > > wrote:
> > >
> > >> Patrick FTW!!!
> > >>
> > >> On Thu, Feb 2, 2023 at 12:32 PM Joseph Lynch 
> > >> wrote:
> > >>
> > >>> W! Congratulations Patrick!!
> > >>>
> > >>> -Joey
> > >>>
> > >>> On Thu, Feb 2, 2023 at 9:58 AM Benjamin Lerer 
> wrote:
> > >>>
> >  The PMC members are pleased to announce that Patrick McFadin has
> >  accepted
> >  the invitation to become committer today.
> > 
> >  Thanks a lot, Patrick, for everything you have done for this project
> >  and its community through the years.
> > 
> >  Congratulations and welcome!
> > 
> >  The Apache Cassandra PMC members
> > 
> > >>> --
> > >
> > > Christopher Bradford
> > >
> > >
> > >
> >
>

Re: Implicitly enabling ALLOW FILTERING on virtual tables

[Andrés de la Peña]

I think removing the need for ALLOW FILTERING on virtual tables makes sense
and would be quite useful for operators.

That guard exists for performance issues that shouldn't occur on virtual
tables. We also have a flag in case some future virtual table
implementation has limitations regarding filtering, although it seems it's
not the case with any of the existing virtual tables.

It is not like we would promote bad habits because virtual tables are meant
to be queried by operators / administrators only.


It might even be quite the opposite, since in the current situation users
might get used to routinely use ALLOW FILTERING for querying their virtual
tables.

It has been mentioned on the #cassandra-dev Slack thread where this started
(1) that it's kind of an API inconsistency to allow querying by non-primary
keys on virtual tables without ALLOW FILTERING, whereas it's required for
regular tables. I think that a simply doc update saying that virtual
tables, which are not regular tables, support filtering would be enough.
Virtual tables are well identified by both the keyspace they belong to and
doc, so users shouldn't have trouble knowing whether a table is virtual. It
would be similar to the current exception for ALLOW FILTERING, where one
needs to use it unless the table has an index for the queried column.

(1) https://the-asf.slack.com/archives/CK23JSY2K/p1675352759267329

On Fri, 3 Feb 2023 at 09:09, Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:

> Hi list,
>
> the content of virtual tables is held in memory (and / or is fetched every
> time upon request). While doing queries against such table for a column
> outside of primary key, normally, users are required to specify ALLOW
> FILTERING. This makes total sense for "ordinary tables" for applications to
> have performant and effective queries but it kinds of loses the
> applicability for virtual tables when it literally holds just handful of
> entries in memory and it just does not matter, does it?
>
> What do you think about implicitly allowing filtering for virtual tables
> so we save ourselves from these pesky errors when we want to query
> arbitrary column and we need to satisfy CQL spec just to do that?
>
> It is not like we would promote bad habits because virtual tables are
> meant to be queried by operators / administrators only.
>
> We can also explicitly document this behavior.
>
> Among other options, we may try to implement secondary indices on virtual
> tables but I am not completely sure this is what we want because its
> complexity etc. Is it even necessary to put such complex logic in place
> just to be able to select any column on few entries in memory?
>
> I put together a draft here (1). It would be ever possible to implicitly
> allow filtering on virtual tables only and it would be implementator's
> responsibility to decide that, per table.
>
> For all virtual tables we currently have, I would enable this everywhere.
> I do not think there is any virtual table where we would not want to enable
> it or where people HAVE TO specify that.
>
> (1) https://github.com/apache/cassandra/pull/2131

Re: [DISCUSS] Merging incremental feature work

[Andrés de la Peña]

I'm not sure a CEP is necessarily a big, complex piece of work that needs
to be split into multiple tickets. There could be single-ticket CEPs that
don't need multiple tickets, and still need the bureaucracy of a CEP due to
the impact of the change. However that probably isn't the common case.

Also, there could be complex CEPs with multiple steps that can be
incrementally merged to trunk because some of the steps have a value on
their own. For example, dynamic data masking (CEP-20) first creates CQL
functions for masking data, then it allows to attach those functions to the
schema, and then it allows to use UDFs as attached masking functions [1].
Each incremental step has a value on its own. For example, the first step
alone is what MySQL dynamic data masking consists on, just a bunch of
functions.

I think that CEP components that offer value on their own to the users can
perfectly be merged to trunk. That's because we could suddenly cut a
release including those changes and be happy with having included them.
However, if there are partial changes that don't give value to the end user
those changes should probably be in a feature branch. And the feature
branch could be merged every time it contains a releasable piece of work.
If the changes on that feature turn out to be massive, it could be a good
idea to create a separate ticket just for the merge, so reviewers can jump
at it and give a final pass with a global perspective.

[1]
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking#CEP20:DynamicDataMasking-Timeline

On Fri, 3 Feb 2023 at 12:48, Sam Tunnicliffe  wrote:

> This is quite timely as we're just gearing up to begin pushing the work
> we've been doing on CEP-21 into the public domain.
>
> This CEP is a slightly different from others that have gone before in that
> it touches almost every area of the system. This presents a few
> implementation challenges, most obviously around feature flagging and
> incremental merging. When we began prototyping and working on the design
> presented in CEP-21 it quickly became apparent that doing things
> incrementally would push an already large changeset into gargantuan
> proportions. Keeping changes isolated and abstracted would itself have
> required a vast amount of refactoring and rework of existing code and
> tests.
>
> I'll go into more detail in a CEP-21 specific mail shortly, but the plan
> we were hoping to follow was to work in a long lived topic branch, with
> JIRAs, sensible commit history and CI, and defer merging to trunk until the
> work as a whole is useable and meets all the existing bars for quality,
> review and the like.
>
>
> On 3 Feb 2023, at 12:43, Josh McKenzie  wrote:
>
> Anything we either a) have to do (JDK support) or b) have all agreed up
> front we think we should do (CEP). I.e. things with a lower risk of being
> left dead in the codebase partially implemented.
>
> I don't think it's a coincidence we've set up other processes to help
> de-risk and streamline the consensus building portion of this work given
> our history with it. We haven't taken steps to optimize the tactical
> execution of it yet.
>
> On Fri, Feb 3, 2023, at 7:09 AM, Brandon Williams wrote:
>
> On Fri, Feb 3, 2023 at 6:06 AM Josh McKenzie  wrote:
> >
> > My current thinking: I'd like to propose we all agree to move to merge
> work into trunk incrementally if it's either:
> > 1) New JDK support
> > 2) An approved CEP
>
> So basically everything?  I'm not sure what large complex bodies of
> work would be left.
>
>
>

Re: [DISCUSS] Merging incremental feature work

[Andrés de la Peña]

Yes, I think that some refactors can also be directly merged if they have a
value for the end user on their own. Changes providing cleaner, better
documented and less tightly coupled code can have that value, even if they
aren't a new feature. Things like new APIs without an implementation
probably don't have that value.

I guess the criteria could be that partial CEP changes can be merged if
they would still make sense if there were a release the next day. Or, even
better, as if the next steps on the CEP were to never be completed.

On Fri, 3 Feb 2023 at 13:13, Josh McKenzie  wrote:

> The deeply coupled nature of some areas of our codebase does have some
> constraints it imposes on us here to your point. Without sensible internal
> APIs a lot of this type of work expands into two phases, one to refactor
> out said APIs and the other to introduce new functionality.
>
> It probably depends on what systems we’re extending or replacing and how
> tightly coupled the original design is as to which approach is feasible
> given resourcing.
>
> On Fri, Feb 3, 2023, at 7:48 AM, Sam Tunnicliffe wrote:
>
> This is quite timely as we're just gearing up to begin pushing the work
> we've been doing on CEP-21 into the public domain.
>
> This CEP is a slightly different from others that have gone before in that
> it touches almost every area of the system. This presents a few
> implementation challenges, most obviously around feature flagging and
> incremental merging. When we began prototyping and working on the design
> presented in CEP-21 it quickly became apparent that doing things
> incrementally would push an already large changeset into gargantuan
> proportions. Keeping changes isolated and abstracted would itself have
> required a vast amount of refactoring and rework of existing code and
> tests.
>
> I'll go into more detail in a CEP-21 specific mail shortly, but the plan
> we were hoping to follow was to work in a long lived topic branch, with
> JIRAs, sensible commit history and CI, and defer merging to trunk until the
> work as a whole is useable and meets all the existing bars for quality,
> review and the like.
>
>
> On 3 Feb 2023, at 12:43, Josh McKenzie  wrote:
>
> Anything we either a) have to do (JDK support) or b) have all agreed up
> front we think we should do (CEP). I.e. things with a lower risk of being
> left dead in the codebase partially implemented.
>
> I don't think it's a coincidence we've set up other processes to help
> de-risk and streamline the consensus building portion of this work given
> our history with it. We haven't taken steps to optimize the tactical
> execution of it yet.
>
> On Fri, Feb 3, 2023, at 7:09 AM, Brandon Williams wrote:
>
> On Fri, Feb 3, 2023 at 6:06 AM Josh McKenzie  wrote:
> >
> > My current thinking: I'd like to propose we all agree to move to merge
> work into trunk incrementally if it's either:
> > 1) New JDK support
> > 2) An approved CEP
>
> So basically everything?  I'm not sure what large complex bodies of
> work would be left.
>
>
>

Re: Implicitly enabling ALLOW FILTERING on virtual tables

[Andrés de la Peña]

For those eventual big virtual tables there is the mentioned flag
indicating whether the table allows filtering without AF.

I guess the question is how can a user know whether a certain virtual table
is one of the big ones. That could be specified in the doc for each table,
and it could also be included in the table properties, so it's displayed by
DESCRIBE TABLE queries.

On Fri, 3 Feb 2023 at 20:56, Chris Lohfink  wrote:

> Just to 2nd what Scott days. While everything is in memory now, it may not
> be in the future, and if we add it implicitly, we are tying ourselves to be
> in memory only. However, I wouldn't -1 the idea.
>
> Another option may be a cqlsh option (ie like expand on/off) to always
> include a flag so it doesnt need to be added or something.
>
> Chris
>
> On Fri, Feb 3, 2023 at 1:24 PM C. Scott Andreas 
> wrote:
>
>> There are some ideas that development community members have kicked
>> around that may falsify the assumption that "virtual tables are tiny and
>> will fit in memory."
>>
>> One example is CASSANDRA-14629: Abstract Virtual Table for very large
>> result sets
>> https://issues.apache.org/jira/browse/CASSANDRA-14629
>>
>> Chris's proposal here is to enable query results from virtual tables to
>> be streamed to the client rather than being fully materialized. There are
>> some neat possibilities suggested in this ticket, such as debug
>> functionality to dump the contents of a raw SSTable via the CQL interface,
>> or the contents of the database's internal caches. One could also imagine a
>> feature like this providing functionality similar to a foreign data wrapper
>> in other databases.
>>
>> I don't think the assumption that "virtual tables will always be small
>> and always fit in memory" is a safe one.
>>
>> I don't think we should implicitly add "ALLOW FILTERING" to all queries
>> against virtual tables because of this, in addition to concern with
>> departing from standard CQL semantics for a type of tables deemed special.
>>
>> – Scott
>>
>> On Feb 3, 2023, at 6:52 AM, Maxim Muzafarov  wrote:
>>
>>
>> Hello Stefan,
>>
>> Regarding the decision to implicitly enable ALLOW FILTERING for
>> virtual tables, which also makes sense to me, it may be necessary to
>> consider changing the clustering columns in the virtual table metadata
>> to regular columns as well. The reasons are the same as mentioned
>> earlier: the virtual tables hold their data in memory, thus we do not
>> benefit from the advantages of ordered data (e.g. the ClientsTable and
>> its ClusteringColumn(PORT)).
>>
>> Changing the clustering column to a regular column may simplify the
>> virtual table data model, but I'm afraid it may affect users who rely
>> on the table metadata.
>>
>>
>>
>> On Fri, 3 Feb 2023 at 12:32, Andrés de la Peña 
>> wrote:
>>
>>
>> I think removing the need for ALLOW FILTERING on virtual tables makes
>> sense and would be quite useful for operators.
>>
>> That guard exists for performance issues that shouldn't occur on virtual
>> tables. We also have a flag in case some future virtual table
>> implementation has limitations regarding filtering, although it seems it's
>> not the case with any of the existing virtual tables.
>>
>> It is not like we would promote bad habits because virtual tables are
>> meant to be queried by operators / administrators only.
>>
>>
>> It might even be quite the opposite, since in the current situation users
>> might get used to routinely use ALLOW FILTERING for querying their virtual
>> tables.
>>
>> It has been mentioned on the #cassandra-dev Slack thread where this
>> started (1) that it's kind of an API inconsistency to allow querying by
>> non-primary keys on virtual tables without ALLOW FILTERING, whereas it's
>> required for regular tables. I think that a simply doc update saying that
>> virtual tables, which are not regular tables, support filtering would be
>> enough. Virtual tables are well identified by both the keyspace they belong
>> to and doc, so users shouldn't have trouble knowing whether a table is
>> virtual. It would be similar to the current exception for ALLOW FILTERING,
>> where one needs to use it unless the table has an index for the queried
>> column.
>>
>> (1) https://the-asf.slack.com/archives/CK23JSY2K/p1675352759267329
>>
>> On Fri, 3 Feb 2023 at 09:09, Miklosovic, Stefan <
>> stefan.mikloso...@netapp.com> wrote:
>>
>&

Re: [VOTE] CEP-21 Transactional Cluster Metadata

[Andrés de la Peña]

+1

On Tue, 7 Feb 2023 at 09:52, Jacek Lewandowski 
wrote:

> +1
>
> - - -- --- -  -
> Jacek Lewandowski
>
>
> wt., 7 lut 2023 o 10:12 Benjamin Lerer  napisał(a):
>
>> +1
>>
>> Le mar. 7 févr. 2023 à 06:21,  a écrit :
>>
>>> +1 nb
>>>
>>> On Feb 6, 2023, at 9:05 PM, Ariel Weisberg  wrote:
>>>
>>> +1
>>>
>>> On Mon, Feb 6, 2023, at 11:15 AM, Sam Tunnicliffe wrote:
>>>
>>> Hi everyone,
>>>
>>> I would like to start a vote on this CEP.
>>>
>>> Proposal:
>>>
>>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata
>>>
>>> Discussion:
>>> https://lists.apache.org/thread/h25skwkbdztz9hj2pxtgh39rnjfzckk7
>>>
>>> The vote will be open for 72 hours.
>>> A vote passes if there are at least three binding +1s and no binding
>>> vetoes.
>>>
>>> Thanks,
>>> Sam
>>>
>>>
>>>

Re: [EXTERNAL] Re: [DISCUSS] Next release date

[Andrés de la Peña]

>
> Should we clarify that part first by getting an idea of the status of the
> different CEPs and other big pieces of work?


CEP-20 (dynamic data masking) should hopefully be ready by the end of this
month.

It's composed by seven small tickets. Five of those tickets are ready, and
two are under review. All together it will be ~6K LOC, involving around 100
files.

On Thu, 9 Mar 2023 at 21:17, Mick Semb Wever  wrote:

> > > > One place we've been weak historically is in distinguishing between
> tickets we consider "nice to have" and things that are "blockers". We don't
> have any metadata that currently distinguishes those two, so determining
> what our burndown leading up to 5.0 looks like is a lot more data massaging
> and hand-waving than I'd prefer right now.
> > >
> > > We distinguish "blockers" with `Priority=Urgent` or
> `Severity=Critical`, or by linking the ticket as blocking to a specific
> ticket that spells it out. We do have the metadata, but yes it requires
> some work…
> >
> > For everything not urgent or a blocker, does it matter whether something
> has a fixver of where we think it's going to land or where we'd like to see
> it land? At the end of the day, neither of those scenarios will actually
> shift a release date if we're proactively putting "blocker / urgent" status
> on new features, improvements, and bugs we think are significant enough to
> delay a release right?
>
>
> Ooops, actually we were using the -beta, and -rc fixVersion
> placeholders to denote the blockers once "the bridge was crossed"
> (while Urgent and Critical is used more broadly, e.g. patch releases).
> If we use this approach, then we could add a 5.0-alpha placeholder
> that indicates a consensus on tickets blocking the branching (if we
> agree alpha1 should be cut at the same time we branch…). IMHO such
> tickets should also still be marked as Urgent, but I suggest we use
> Urgent/Critical as an initial state, and the fixVersion placeholders
> where we have consensus or it is according to our release criteria
> :shrug:
>

[DISCUSS] Remove deprecated CQL functions dateof and unixtimestampof on 5.0

[Andrés de la Peña]

The CQL functions "dateof" and "unixtimestampof" were deprecated on
Cassandra 2.2.0, almost eight years ago [1]. They were deprecated in favour
of the then new "totimestamp" and "tounixtimestamp" functions.

I think that we can finally remove those functions in 5.0, since they have
been deprecated for so long.

A note about their deprecation was added to NEWS.txt [2], and they were
marked as deprecated on CQL.textile [3]. They are also listed as deprecated
on the new doc [4].

I came to this while working on the adoption of snake case conventions for
CQL function names on CASSANDRA-18037. It probably doesn't make sense to
add new "date_of" and "unix_timestamp_of" aliases for them.

What do you think? Should we remove them?

[1]
https://github.com/apache/cassandra/commit/c08aaabd95d4872593c29807de6ec1485cefa7fa
[2] https://github.com/apache/cassandra/blob/trunk/NEWS.txt#L1421-L1423
[3]
https://github.com/apache/cassandra/blob/trunk/doc/cql3/CQL.textile#time-conversion-functions
[4]
https://github.com/apache/cassandra/blob/trunk/doc/modules/cassandra/pages/cql/functions.adoc#time-conversion-functions

Re: [DISCUSS] Remove deprecated CQL functions dateof and unixtimestampof on 5.0

[Andrés de la Peña]

I have created https://issues.apache.org/jira/browse/CASSANDRA-18328 for
removing the deprecated functions, as part of CASSANDRA-18306
<https://issues.apache.org/jira/browse/CASSANDRA-18306> epic.

On Mon, 13 Mar 2023 at 12:28, Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:

> Actually, this one https://issues.apache.org/jira/browse/CASSANDRA-18306
>
> 
> From: Miklosovic, Stefan 
> Sent: Monday, March 13, 2023 13:26
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSS] Remove deprecated CQL functions dateof and
> unixtimestampof on 5.0
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
>
> I am +1.
>
> Could you please link the ticket to
> https://issues.apache.org/jira/browse/CASSANDRA-17973 ?
>
> Thanks
>
> 
> From: Andrés de la Peña 
> Sent: Monday, March 13, 2023 13:22
> To: dev@cassandra.apache.org
> Subject: [DISCUSS] Remove deprecated CQL functions dateof and
> unixtimestampof on 5.0
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
> The CQL functions "dateof" and "unixtimestampof" were deprecated on
> Cassandra 2.2.0, almost eight years ago [1]. They were deprecated in favour
> of the then new "totimestamp" and "tounixtimestamp" functions.
>
> I think that we can finally remove those functions in 5.0, since they have
> been deprecated for so long.
>
> A note about their deprecation was added to NEWS.txt [2], and they were
> marked as deprecated on CQL.textile [3]. They are also listed as deprecated
> on the new doc [4].
>
> I came to this while working on the adoption of snake case conventions for
> CQL function names on CASSANDRA-18037. It probably doesn't make sense to
> add new "date_of" and "unix_timestamp_of" aliases for them.
>
> What do you think? Should we remove them?
>
> [1]
> https://github.com/apache/cassandra/commit/c08aaabd95d4872593c29807de6ec1485cefa7fa
> [2] https://github.com/apache/cassandra/blob/trunk/NEWS.txt#L1421-L1423
> [3]
> https://github.com/apache/cassandra/blob/trunk/doc/cql3/CQL.textile#time-conversion-functions
> [4]
> https://github.com/apache/cassandra/blob/trunk/doc/modules/cassandra/pages/cql/functions.adoc#time-conversion-functions
>

Re: Welcome our next PMC Chair Josh McKenzie

[Andrés de la Peña]

Congratulations Josh! Thanks for everything Mick!

On Thu, 23 Mar 2023 at 11:36, Ekaterina Dimitrova 
wrote:

> Congrats Josh!  Thanks Mick!
>
> На четвъртък, 23 март 2023 г. Brandon Williams  написа:
>
>> Congrats Josh!  Thanks Mick!
>>
>> Kind Regards,
>> Brandon
>>
>> On Thu, Mar 23, 2023 at 3:22 AM Mick Semb Wever  wrote:
>> >
>> > It is time to pass the baton on, and on behalf of the Apache Cassandra
>> Project Management Committee (PMC) I would like to welcome and congratulate
>> our next PMC Chair Josh McKenzie (jmckenzie).
>> >
>> > Most of you already know Josh, especially through his regular and
>> valuable project oversight and status emails, always presenting a balance
>> and understanding to the various views and concerns incoming.
>> >
>> > Repeating Paulo's words from last year: The chair is an administrative
>> position that interfaces with the Apache Software Foundation Board, by
>> submitting regular reports about project status and health. Read more about
>> the PMC chair role on Apache projects:
>> > - https://www.apache.org/foundation/how-it-works.html#pmc
>> > - https://www.apache.org/foundation/how-it-works.html#pmc-chair
>> > -
>> https://www.apache.org/foundation/faq.html#why-are-PMC-chairs-officers
>> >
>> > The PMC as a whole is the entity that oversees and leads the project
>> and any PMC member can be approached as a representative of the committee.
>> A list of Apache Cassandra PMC members can be found on:
>> https://cassandra.apache.org/_/community.html
>>
>

Re: [VOTE] CEP-26: Unified Compaction Strategy

[Andrés de la Peña]

+1

On Tue, 4 Apr 2023 at 15:09, Jeremy Hanna 
wrote:

> +1 nb, will be great to have this in the codebase - it will make nearly
> every table's compaction work more efficiently.  The only possible
> exception is tables that are well suited for TWCS.
>
> On Apr 4, 2023, at 8:00 AM, Berenguer Blasi 
> wrote:
>
> +1
> On 4/4/23 14:36, J. D. Jordan wrote:
>
> +1
>
> On Apr 4, 2023, at 7:29 AM, Brandon Williams 
>  wrote:
>
> 
> +1
>
> On Tue, Apr 4, 2023, 7:24 AM Branimir Lambov  wrote:
>
>> Hi everyone,
>>
>> I would like to put CEP-26 to a vote.
>>
>> Proposal:
>>
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-26%3A+Unified+Compaction+Strategy
>>
>> JIRA and draft implementation:
>> https://issues.apache.org/jira/browse/CASSANDRA-18397
>>
>> Up-to-date documentation:
>>
>> https://github.com/blambov/cassandra/blob/CASSANDRA-18397/src/java/org/apache/cassandra/db/compaction/UnifiedCompactionStrategy.md
>>
>> Discussion:
>> https://lists.apache.org/thread/8xf5245tclf1mb18055px47b982rdg4b
>>
>> The vote will be open for 72 hours.
>> A vote passes if there are at least three binding +1s and no binding
>> vetoes.
>>
>> Thanks,
>> Branimir
>>
>
>

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Andrés de la Peña]

I think supporting DATABASE is a great idea.

It's better aligned with SQL databases, and can save new users one of the
first troubles they find.

Probably anyone starting to use Cassandra for the first time is going to
face the what is a keyspace? question in the first minutes. Saving that to
users with a more common name would be a victory for usability IMO.

On Tue, 4 Apr 2023 at 16:48, Mike Adamson  wrote:

> Hi,
>
> I'd like to propose that we add DATABASE to the CQL grammar as an
> alternative to KEYSPACE.
>
> Background: While TABLE was introduced as an alternative for COLUMNFAMILY
> in the grammar we have kept KEYSPACE for the container name for a group of
> tables. Nearly all traditional SQL databases use DATABASE as the container
> name for a group of tables so it would make sense for Cassandra to adopt
> this naming as well.
>
> KEYSPACE would be kept in the grammar but we would update some logging and
> documentation to encourage use of the new name.
>
> Mike Adamson
>
> --
> [image: DataStax Logo Square]  *Mike Adamson*
> Engineering
>
> +1 650 389 6000 <16503896000> | datastax.com 
> Find DataStax Online: [image: LinkedIn Logo]
> 
>[image: Facebook Logo]
> 
>[image: Twitter Logo]    [image: RSS
> Feed]    [image: Github Logo]
> 
>
>

Re: [DISCUSS] CEP-29 CQL NOT Operator

[Andrés de la Peña]

Indeed requiring AF for "select * from ks.tb where p1 = 1 and c1 = 2 and
col2 = 1", where p1 and c1 are all the columns in the primary key, sounds
like a bug.

I think the criterion in the code is that we require AF if there is any
column restriction that cannot be processed by the primary key or a
secondary index. The error message indeed seems to reject any kind of
filtering, independently of primary key filters. We can see this even
without defined clustering keys:

CREATE TABLE t (k int PRIMARY KEY, v int);
SELECT * FROM  t WHERE  k = 1 AND v = 1; # requires AF

That clashes with documentation, where it's said that AF is required for
filters that require scanning all partitions. If we were to adapt the code
to the behaviour described in documentation we shouldn't require AF if
there are restrictions specifying a partition key. Or possibly a group of
partition keys, if a IN restriction is used. So both within row and within
partition filtering wouldn't require AF.

Regarding adding a new ALLOW FILTERING WITHIN PARTITION, I think we could
just add a guardrail to directly disallow those queries, without needing to
add the WITHIN PARTITION clause to the CQL grammar.

On Thu, 13 Apr 2023 at 11:11, Henrik Ingo  wrote:

>
>
> On Thu, Apr 13, 2023 at 10:20 AM Miklosovic, Stefan <
> stefan.mikloso...@netapp.com> wrote:
>
>> Somebody correct me if I am wrong but "partition key" itself is not
>> enough (primary keys = partition keys + clustering columns). It will
>> require ALLOW FILTERING when clustering columns are not specified either.
>>
>> create table ks.tb (p1 int, c1 int, col1 int, col2 int, primary key (p1,
>> c1));
>> select * from ks.tb where p1 = 1 and col1 = 2; // this will require
>> allow filtering
>>
>> The documentation seems to omit this fact.
>>
>
> It does seem so.
>
> That said, personally I was assuming, and would still argue it's the
> optimal choice, that the documentation was right and reality is wrong.
>
> If there is a partition key, then the query can avoid scanning the entire
> table, across all nodes, potentially petabytes.
>
> If a query specifies a partition key but not the full clustering key, of
> course there will be some scanning needed, but this is marginal compared to
> the need to scan the entire table. Even in the worst case, a partition with
> 2 billion cells, we are talking about seconds to filter the result from the
> single partition.
>
> > Aha I get what you all mean:
>
> No, I actually think both are unnecessary. But yeah, certainly this latter
> case is a bug?
>
> henrik
>
> --
>
> Henrik Ingo
>
> c. +358 40 569 7354
>
> w. www.datastax.com
>
>   
> 
> 
>
>

Re: [DISCUSS] New data type for vector search

[Andrés de la Peña]

If we are going to use FLOAT[N] as sugar for another CQL data type, maybe
tuples are more convenient than lists. So FLOAT[N] could be equivalent to
TUPLE.

Differently to collections, tuples have a fixed size, they are always
frozen and I think they don't support random access. These properties seem
desirable for vectors.

Tuples however support null values, whereas collections doesn't. I mean,
you can remove elements from a collection, but I think you are never going
to see an explicit null in the collection. Tuples don't allow to remove a
value, but the entire tuple can be written with null values. Like in INSERT
INTO t (key, tuple) VALUES (0,  (1, null, 3)).

On Wed, 26 Apr 2023 at 21:53, Mick Semb Wever  wrote:

> My inclination then would be to say you declare an ARRAY (which
>> is semantic sugar for FROZEN>). This is very consistent with
>> our existing style. We then simply permit such columns to define ANN
>> indexes.
>>
>
>
> So long as nulls aren't a problem as David questions, an alternative is:
>
>  FLOAT[N] as semantic sugar for LIST
>
> And ANN requiring FROZEN
>
> Maybe taking a poll in a few days will be positive to keep this
> moving forward.
>

Re: [POLL] Vector type for ML

[Andrés de la Peña]

A > B > C

I don't think that ML is such a niche application that it can't have its
own CQL data type. Also, vectors are mathematical elements that have more
applications that ML.

On Tue, 2 May 2023 at 19:15, Mick Semb Wever  wrote:

>
>
> On Tue, 2 May 2023 at 17:14, Jonathan Ellis  wrote:
>
>> Should we add a vector type to Cassandra designed to meet the needs of
>> machine learning use cases, specifically feature and embedding vectors for
>> training, inference, and vector search?
>>
>> ML vectors are fixed-dimension (fixed-length) sequences of numeric types,
>> with no nulls allowed, and with no need for random access. The ML industry
>> overwhelmingly uses float32 vectors, to the point that the industry-leading
>> special-purpose vector database ONLY supports that data type.
>>
>> This poll is to gauge consensus subsequent to the recent discussion
>> thread at
>> https://lists.apache.org/thread/0lj1nk9jbhkf1rlgqcvxqzfyntdjrnk0.
>>
>> Please rank the discussed options from most preferred option to least,
>> e.g., A > B > C (A is my preference, followed by B, followed by C) or C > B
>> = A (C is my preference, followed by B or A approximately equally.)
>>
>> (A) I am in favor of adding a vector type for floats; I do not believe we
>> need to tie it to any particular implementation details.
>>
>> (B) I am okay with adding a vector type but I believe we must add array
>> types that compose with all Cassandra types first, and make vectors a
>> special case of arrays-without-null-elements.
>>
>> (C) I am not in favor of adding a built-in vector type.
>>
>
>
>
> A  > B > C
>
> B is stated as "must add array types…".  I think this is a bit loaded.  If
> B was the (A + the implementation needs to be a non-null frozen float32
> array, serialisation forward compatible with other frozen arrays later
> implemented) I would put this before (A).  Especially because it's been
> shown already this is easy to implement.
>
>
>

Re: [POLL] Vector type for ML

[Andrés de la Peña]

My vote is:

1. VECTOR
2. DENSE VECTOR
3. type[dimension]

If we ever add sparse vectors, we can assume that DENSE is the default and
allow to use either DENSE, SPARSE or nothing.

Perhaps the dimension could be separated from the type, such as in
VECTOR[dimension] or VECTOR(dimension).

On Fri, 5 May 2023 at 19:05, David Capwell  wrote:

> ...where, just to be clear, VECTOR means a frozen fixed
>> size array w/ no null values?
>>
> Assuming this is the case
>
>
> The current agreed requirements are:
>
> 1) non-null elements
> 2) fixed length
> 3) frozen
>
> You pointed out 3 isn’t actually required, but that would be a different
> conversation to remove =)… maybe defer this to JIRA as long as all parties
> agree in the ticket?
>
> With all votes in, this is what I see
>
> *Syntax*
>
> *Jonathan Ellis*
>
> *David Capwell*
>
> *Josh McKenzie*
>
> *Caleb Rackliffe*
>
> *Patrick McFadin*
>
> *Brandon Williams*
>
> *Mike Adamson*
>
> *Benedict*
>
> *Mick Semb Wever*
>
> *Derek Chen-Becker*
>
> VECTOR
>
> 1
>
> 2
>
> 2
>
>
> 2
>
> 1
>
> 1
>
> 3
>
> 2
>
>
> DENSE VECTOR
>
> 2
>
> 1
>
>
>
> 1
>
>
> 2
>
>
>
>
> type[dimension]
>
> 3
>
> 3
>
> 3
>
> 1
>
>
> 3
>
>
> 2
>
>
>
> DENSE_VECTOR
>
>
>
> 1
>
>
>
>
>
>
>
> 3
>
> NON NULL [dimention]
>
>
> 1
>
>
>
>
>
>
> 1
>
>
> 2
>
> VECTOR type[n]
>
>
>
>
>
>
> 2
>
>
>
> 1
>
>
> ARRAY
>
>
>
>
>
> 3
>
>
>
>
>
>
> NON-NULL FROZEN
>
>
>
>
>
>
>
>
>
>
> 1
>
> *Rank*
>
> *Weight*
>
> *1*
>
> 3
>
> *2*
>
> 2
>
> *3*
>
> 1
>
> *?*
>
> 3
>
> *Syntax*
>
> *Score*
>
> VECTOR
>
> 18
>
> DENSE VECTOR
>
> 10
>
> type[dimension]
>
> 9
>
> NON NULL [dimention]
>
> 8
>
> VECTOR type[n]
>
> 5
>
> DENSE_VECTOR
>
> 4
>
> NON-NULL FROZEN
>
> 3
>
> ARRAY
>
> 1
>
>
> *Syntax*
>
> *Round 1*
>
> *Round 2*
>
> VECTOR
>
> 3
>
> 4
>
> DENSE VECTOR
>
> 2
>
> 2
>
> NON NULL [dimention]
>
> 2
>
> 1
>
> VECTOR type[n]
>
> 1
>
>
> type[dimension]
>
> 1
>
>
> DENSE_VECTOR
>
> 1
>
>
> NON-NULL FROZEN
>
> 1
>
>
> ARRAY
>
> 0
>
>
>
> Under 2 different voting systems vector is in the lead
> and by a good amount… I have updated the patch locally to reflect this
> change as well.
>
> On May 5, 2023, at 10:41 AM, Mike Adamson  wrote:
>
> ...where, just to be clear, VECTOR means a frozen fixed
>> size array w/ no null values?
>>
> Assuming this is the case, my vote is:
>
> 1. VECTOR
> 2. DENSE VECTOR
>
> I don't really have a 3rd vote because I think that *type[dimension]* is
> too ambiguous.
>
>
> On Fri, 5 May 2023 at 18:32, Derek Chen-Becker 
> wrote:
>
>> LOL, I'm holding you to that at the summit :) In all seriousness, I'm
>> glad to see a robust debate around it. I guess for completeness, my order
>> of preference is
>>
>> 1 - NONNULL FROZEN>
>> 2 - NONNULL TYPE (which part of this implies frozen? The NONNULL or
>> the cardinality?)
>> 3 - DENSE_VECTOR
>>
>> I guess my main concern with just "VECTOR" is that it's such an
>> overloaded term. Maybe in ML it means something specific, but for anyone
>> coming from C++, Rust, Java, etc, a Vector is both mutable and can carry
>> null (or equivalent, e.g. None, in Rust). If the argument hadn't also been
>> made that we should be working toward something that's not ML-specific
>> maybe I would be less concerned.
>>
>> Cheers,
>>
>> Derek
>>
>>
>> Cheers,
>>
>> Derek
>>
>> On Fri, May 5, 2023 at 11:14 AM Patrick McFadin 
>> wrote:
>>
>>> Derek, despite your preference, I would hang out with you at a party.
>>>
>>> On Fri, May 5, 2023 at 9:44 AM Derek Chen-Becker 
>>> wrote:
>>>
 Speaking as someone who likes Erlang, maybe that's why I also like
 NONNULL FROZEN>. It's unambiguous what Cassandra is going to do
 with that type. DENSE VECTOR means I need to go read docs (and then
 probably double-check in the source to be sure) to be sure what exactly is
 going on.

 Cheers,

 Derek

 On Fri, May 5, 2023 at 9:54 AM Patrick McFadin 
 wrote:

> I hope we are willing to consider developers that use our system
> because if I had to teach people to use "NON-NULL FROZEN" I'm
> pretty sure the response would be:
>
> Did you tell me to go write a distributed map-reduce job in Erlang? I
> beleive I did, Bob.
>
> On Fri, May 5, 2023 at 8:05 AM Josh McKenzie 
> wrote:
>
>> Idiomatically, to my mind, there's a question of "what space are we
>> thinking about this datatype in"?
>>
>> - In the context of mathematics, nullability in a vector would be 0
>> - In the context of Cassandra, nullability tends to mean a tombstone
>> (or nothing)
>> - In the context of programming languages, it's all over the place
>>
>> Given many models are exploring quantizing to int8 and other data
>> types, there's definitely the "support other data types easily in the
>> future" piece to me we need to keep in mind.
>>
>> So with the above and the "meet the user where they are and don't
>> make them understand more of Cassandra than absolutely critical to use

Re: [VOTE] Release dtest-api 0.0.14

[Andrés de la Peña]

+1

On Tue, 16 May 2023 at 07:24, Alex Petrov  wrote:

> +1
>
> On Tue, May 16, 2023, at 4:45 AM, Doug Rohrer wrote:
>
> +1 (nb)
>
> Doug Rohrer
>
> > On May 15, 2023, at 7:17 PM, Brandon Williams  wrote:
> >
> > +1
> >
> > Kind Regards,
> > Brandon
> >
> >> On Mon, May 15, 2023 at 5:12 PM Dinesh Joshi  wrote:
> >>
> >> Proposing the test build of in-jvm dtest API 0.0.14 for release.
> >>
> >> Repository:
> >> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git
> >>
> >> Candidate SHA:
> >>
> https://github.com/apache/cassandra-in-jvm-dtest-api/commit/ea4b44e0ed0a4f0bbe9b18fb40ad927b49a73a32
> >> tagged with 0.0.14
> >>
> >> Artifacts:
> >>
> https://repository.apache.org/content/repositories/orgapachecassandra-1289/org/apache/cassandra/dtest-api/0.0.14/
> >>
> >> Key signature: 53371F9B1B425A336988B6A03B6042413D323470
> >>
> >> Changes since last release:
> >>
> >> * CASSANDRA-18511: Add support for JMX in jvm-dtest
> >>
> >> The vote will be open for 24 hours. 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.
>
>

Re: [VOTE] CEP-30 ANN Vector Search

[Andrés de la Peña]

+1

On Fri, 26 May 2023 at 12:59, Mike Adamson  wrote:

> +1 (nb)
>
> On Fri, 26 May 2023 at 12:50, Stefania Alborghetti 
> wrote:
>
>> +1
>>
>> On Fri, May 26, 2023 at 7:31 AM Aleksey Yeshchenko 
>> wrote:
>>
>>> +1
>>>
>>> On 26 May 2023, at 07:19, Berenguer Blasi 
>>> wrote:
>>>
>>> +1
>>> On 26/5/23 6:07, guo Maxwell wrote:
>>>
>>> +1
>>>
>>> Dinesh Joshi 于2023年5月26日 周五上午11:08写道：
>>>
 +1


 On May 25, 2023, at 8:45 AM, Jonathan Ellis  wrote:

 

 Let's make this official.

 CEP:
 https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-30%3A+Approximate+Nearest+Neighbor%28ANN%29+Vector+Search+via+Storage-Attached+Indexes

 POC that demonstrates all the big rocks, including distributed queries:
 https://github.com/datastax/cassandra/tree/cep-vsearch

 --
 Jonathan Ellis
 co-founder, http://www.datastax.com
 @spyced

 --
>>> you are the apple of my eye !
>>>
>>>
>>>
>
> --
> [image: DataStax Logo Square]  *Mike Adamson*
> Engineering
>
> +1 650 389 6000 <16503896000> | datastax.com 
> Find DataStax Online: [image: LinkedIn Logo]
> 
>[image: Facebook Logo]
> 
>[image: Twitter Logo]    [image: RSS
> Feed]    [image: Github Logo]
> 
>
>

Re: [VOTE] CEP-8 Datastax Drivers Donation

[Andrés de la Peña]

+1

On Tue, 13 Jun 2023 at 16:40, Yifan Cai  wrote:

> +1
> --
> *From:* David Capwell 
> *Sent:* Tuesday, June 13, 2023 8:37:10 AM
> *To:* dev 
> *Subject:* Re: [VOTE] CEP-8 Datastax Drivers Donation
>
> +1
>
> On Jun 13, 2023, at 7:59 AM, Josh McKenzie  wrote:
>
> +1
>
> On Tue, Jun 13, 2023, at 10:55 AM, Jeremiah Jordan wrote:
>
> +1 nb
>
> On Jun 13, 2023 at 9:14:35 AM, Jeremy Hanna 
> wrote:
>
>
> Calling for a vote on CEP-8 [1].
>
> To clarify the intent, as Benjamin said in the discussion thread [2], the
> goal of this vote is simply to ensure that the community is in favor of
> the donation. Nothing more.
> The plan is to introduce the drivers, one by one. Each driver donation
> will need to be accepted first by the PMC members, as it is the case for
> any donation. Therefore the PMC should have full control on the pace at
> which new drivers are accepted.
>
> If this vote passes, we can start this process for the Java driver under
> the direction of the PMC.
>
> Jeremy
>
> 1.
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+Datastax+Drivers+Donation
> 2. https://lists.apache.org/thread/opt630do09phh7hlt28odztxdv6g58dp
>
>
>

Re: [DISCUSS] Remove deprecated keyspace_count_warn_threshold and table_count_warn_threshold

[Andrés de la Peña]

Indeed "keyspace_count_warn_threshold" and "table_count_warn_threshold"
include system keyspaces and tables. Also, differently to the newer
guardrails, they are enabled by default.

I find that problematic because users need to know how many system
keyspaces/tables there are to know if they need to set the threshold value.
Moreover, if a new release adds some system tables, the threshold can start
to be triggered without changing the number of user tables. That would
force some users to update the threshold values during an upgrade. Even if
they are using the defaults. That situation would happen again in any
release adding new keyspaces/tables. I think adding new system tables is
not that uncommon, and indeed 5.0 does it.

I think that the combined decision of using a default value and counting
system tables was a mistake. If that's the case, I don't know for how long
we want to remain tied to that mistake. Especially when the old thresholds
tend to create upgrade issues on their own.

If we were going to use converters, we would need to know how many system
keyspaces/tables were on the version we are upgrading from. I don't know if
that information is available. Or perhaps we could assume that counting
system keyspaces/tables was a bug, and just translate changing the meaning
to not include them.





On Tue, 13 Jun 2023 at 16:51, David Capwell  wrote:

> > Have we been dropping support entirely for old params or using the
> @Replaces annotation into perpetuity?
>
>
> My understanding is that the goal is to keep things around in perpetuity
> unless it actively causes us harm… and with @Replaces, there tends to be no
> harm to keep around…
>
> Looking at
> https://github.com/apache/cassandra/commit/bae92ee139b411c94228f8fd5bb8befb4183ca9f
> we just marked them deprecated and created a brand new config that matched
> the old… which I feel was a bad idea…. Renaming configs are fine with
> @Replaces, but asking users to migrate with the idea of breaking them in
> the future is bad…
>
> The table_count_warn_threshold config is used at
> org.apache.cassandra.cql3.statements.schema.CreateTableStatement#clientWarnings
> The tables_warn_threshold config is used at
> org.apache.cassandra.cql3.statements.schema.CreateTableStatement#validate
>
> The only difference I see is that table_count_warn_threshold includes
> system tables where as tables_warn_threshold is only user tables…
>
> > I would like to propose removing the non-guardrail thresholds
> 'keyspace_count_warn_threshold' and 'table_count_warn_threshold'
> configuration settings on the trunk branch for the next major release.
>
> Deprecate in 4.1 is way too new for me to accept that, and its low effort
> to keep; breaking users is always a bad idea and doing it when not needed
> is bad…
>
> Honestly, I don’t see why we couldn’t use @Replaces here to solve the
> semantic gap… table_count_warn_threshold includes the system tables, so we
> just need a Converter that takes w/e the value the user put in and
> subtracts the system tables… which then gives us the user tables (matching
> tables_warn_threshold)
>
> > On Jun 13, 2023, at 7:57 AM, Josh McKenzie  wrote:
> >
> >> have subsequently been deprecated since 4.1-alpha in CASSANDRA-17195
> when they were replaced/migrated to guardrails as part of CEP-3
> (Guardrails).
> > Have we been dropping support entirely for old params or using the
> @Replaces annotation into perpetuity?
> >
> > I dislike the idea of operators having to remember to update things
> between versions and being surprised when things change roughly equally to
> us carrying along undocumented deprecated param name mapping roughly
> equally. :)
> >
> > On Mon, Jun 12, 2023, at 5:56 PM, Dan Jatnieks wrote:
> >> Hello everyone,
> >>
> >> I would like to propose removing the non-guardrail thresholds
> 'keyspace_count_warn_threshold' and 'table_count_warn_threshold'
> configuration settings on the trunk branch for the next major release.
> >>
> >> These thresholds were first added with CASSANDRA-16309 in 4.0-beta4 and
> have subsequently been deprecated since 4.1-alpha in CASSANDRA-17195 when
> they were replaced/migrated to guardrails as part of CEP-3 (Guardrails).
> >>
> >> I'd appreciate any thoughts about this. I will open a ticket to get
> started if there is support for doing this.
> >>
> >> Reference:
> >> https://issues.apache.org/jira/browse/CASSANDRA-16309
> >> https://issues.apache.org/jira/browse/CASSANDRA-17195
> >> CEP-3: Guardrails
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-3%3A+Guardrails
> >>
> >>
> >> Thanks,
> >> Dan Jatnieks
>
>
>

Re: [DISCUSS] Remove deprecated keyspace_count_warn_threshold and table_count_warn_threshold

[Andrés de la Peña]

>
> > Default value I agree with you; features should be off by default!  If
> we remove the default then we disable the feature by default (which im cool
> with) and for anyone who changed the config, they would keep their behavior


I'm glad we agree on at least removing the default value if we keep the
deprecated properties.

> With that, I kinda don’t agree that including system tables is a mistake,
> as we add more we allow less for user tables before we start to have
> issues….


That's problematic because the new thresholds we added in CASSANDRA-17147
don't include system tables. Do you think we should change that?

I still think it's better not to include the system tables in the count.
The thresholds on the number of keyspaces/tables/rows/columns/tombstones
are just guidance since they cannot be exactly related to exact resource
consumption. The main purpose of those thresholds is to prevent obvious
antipatterns such as creating thousands of tables. A benefit of expressing
the guardrails in terms of the number of schema entities, rather than
counting the memory usage of those entities, is that they are easy to
understand and reason about. In my opinion including system tables defeats
that purpose because it forces users to know details about the system
tables. The fact that those details change between versions doesn't help.
Including system tables is not going to make the thresholds precise in
terms of measuring memory consumption because that depends on other
factors, such as the columns they store.

Including system tables also imposes a minimum threshold value, like in 5.0
you cannot set a threshold value under 45 tables without triggering it with
an empty db. For other thresholds, this can be more tricky. That would be
the case of the guardrail on the number of columns in a partition, where
you would need to know the size of the widest row in the system tables,
which can change over time.

I guess that if system tables were to be counted, a recommendation for the
threshold would say something like "It's recommended not to have more than
150 tables. The system already includes 45 tables for internal usage, so
you shouldn't create more than 105 user tables". I find it's better for
usability to not count the system tables and just say "It's recommended not
to have more than 100 tables. This doesn't include system tables."

On Tue, 13 Jun 2023 at 23:51, Josh McKenzie  wrote:

> Warning that too many tables (including system) may have negative behavior
> I think is fine
>
> This reminds me of the current situation with our tests where we just keep
> adding more and more without really considering the value of the current
> set and the costs of that body of work as it keeps growing.
>
> Having some kind of signal that we need to do some housekeeping with our
> system tables, or *something* in the feedback loop that helps us keep on
> top of this hygiene over time, seems like a clear benefit to me.
>
> On Tue, Jun 13, 2023, at 1:42 PM, David Capwell wrote:
>
> I think that the combined decision of using a default value and counting
> system tables was a mistake
>
>
> Default value I agree with you; features should be off by default!  If we
> remove the default then we disable the feature by default (which im cool
> with) and for anyone who changed the config, they would keep their behavior
>
> As for system tables… each table adds a cost to our bookkeeping, so when
> we add new tables the cost grows and the memory per table decreases, does
> it not?  Warning that too many tables (including system) may have negative
> behavior I think is fine, its only if we start to fail is when things
> become a problem (upgrading to 5.0 can’t happen due to too many tables
> added in the release?); think the feature was warn only, so that should be
> fine.  With that, I kinda don’t agree that including system tables is a
> mistake, as we add more we allow less for user tables before we start to
> have issues…. At the same time, if we have improvements in newer versions
> that allows higher number of tables, the user then has to update their
> configs (well, as long as we don’t make things worse a smaller limit than
> needed is fine…)
>
> we would need to know how many system keyspaces/tables were on the version
> we are upgrading from
>
>
> Do we?  The logic was pulling from local schema, so to keep the same
> behavior we would need to do the same; being version dependent would
> actually break the semantics as far as I can tell.
>
> On Jun 13, 2023, at 9:50 AM, Andrés de la Peña 
> wrote:
>
> Indeed "keyspace_count_warn_threshold" and "table_count_warn_threshold"
> include system keyspaces and tables. Also, differently to the newer
> guardrails, they 

Re: [DISCUSS] Remove deprecated keyspace_count_warn_threshold and table_count_warn_threshold

[Andrés de la Peña]

It seems we agree on removing the default value for the old thresholds, and
don't count system keyspaces/tables on the new ones.

The old thresholds were on active duty for around ten months, and they have
been deprecated for around a year. They will have been deprecated for
longer by the time we release 5.0. If we want to keep them in perpetuity, I
guess the plan would be:

- Remove the default value of the old thresholds in Config.java to make
them disabled by default.
- Remove the old thresholds from the default cassandra.yaml, although old
yamls can still have them.
- Use converters (@Replaces tag in Config.java) to read the old threshold
values (if present) and apply them to the new guardrails.
- During the conversion from the old thresholds to the new guardrails,
subtract the current number of system keyspace/tables from the old value.
For example, 150 tables in the old threshold translate to 103 tables in the
new guardrail, considering that there are 47 system tables.

Does this sound good?

On Wed, 14 Jun 2023 at 17:26, David Capwell  wrote:

> That's problematic because the new thresholds we added in CASSANDRA-17147
> don't include system tables. Do you think we should change that?
>
>
> I wouldn’t change the semantics of the config as it’s already live.  I
> guess where I am coming from is that logically we have to think about the
> system tables, so to your point, if we think 150 is too much and the system
> already exposes 50… then we should recommend no more than 100….
>
> I find it's better for usability to not count the system tables and just
> say "It's recommended not to have more than 100 tables. This doesn't
> include system tables.”
>
>
> I am fine with this framing… internally we think about 150 but
> publicly speak 100 (due to our 50 tables)...
>
>
> On Jun 14, 2023, at 8:29 AM, Josh McKenzie  wrote:
>
> In my opinion including system tables defeats that purpose because it
> forces users to know details about the system tables.
>
> Perhaps having a unit test that caps our system tables at some value and
> keeping the guardrail user-scope specific would be a better approach. I see
> your point about leaking internal details to users, specifically on things
> they can't control at this point.
>
> On Wed, Jun 14, 2023, at 8:19 AM, Andrés de la Peña wrote:
>
> > Default value I agree with you; features should be off by default!  If
> we remove the default then we disable the feature by default (which im cool
> with) and for anyone who changed the config, they would keep their behavior
>
>
> I'm glad we agree on at least removing the default value if we keep the
> deprecated properties.
>
> > With that, I kinda don’t agree that including system tables is a
> mistake, as we add more we allow less for user tables before we start to
> have issues….
>
>
> That's problematic because the new thresholds we added in CASSANDRA-17147
> don't include system tables. Do you think we should change that?
>
> I still think it's better not to include the system tables in the count.
> The thresholds on the number of keyspaces/tables/rows/columns/tombstones
> are just guidance since they cannot be exactly related to exact resource
> consumption. The main purpose of those thresholds is to prevent obvious
> antipatterns such as creating thousands of tables. A benefit of expressing
> the guardrails in terms of the number of schema entities, rather than
> counting the memory usage of those entities, is that they are easy to
> understand and reason about. In my opinion including system tables defeats
> that purpose because it forces users to know details about the system
> tables. The fact that those details change between versions doesn't help.
> Including system tables is not going to make the thresholds precise in
> terms of measuring memory consumption because that depends on other
> factors, such as the columns they store.
>
> Including system tables also imposes a minimum threshold value, like in
> 5.0 you cannot set a threshold value under 45 tables without triggering it
> with an empty db. For other thresholds, this can be more tricky. That would
> be the case of the guardrail on the number of columns in a partition, where
> you would need to know the size of the widest row in the system tables,
> which can change over time.
>
> I guess that if system tables were to be counted, a recommendation for the
> threshold would say something like "It's recommended not to have more than
> 150 tables. The system already includes 45 tables for internal usage, so
> you shouldn't create more than 105 user tables". I find it's better for
> usability to not count the system tables and just say "It

Re: Fwd: [DISCUSS] Formalizing requirements for pre-commit patches on new CI

[Andrés de la Peña]

I think 500 runs combining all configs could be reasonable, since it's
unlikely to have config-specific flaky tests. As in five configs with 100
repetitions each.

On Fri, 7 Jul 2023 at 16:14, Josh McKenzie  wrote:

> Maybe. Kind of depends on how long we write our tests to run doesn't it? :)
>
> But point taken. Any non-trivial test would start to be something of a
> beast under this approach.
>
> On Fri, Jul 7, 2023, at 11:12 AM, Brandon Williams wrote:
>
> On Fri, Jul 7, 2023 at 10:09 AM Josh McKenzie 
> wrote:
> > 3. Multiplexed tests (changed, added) run against all JDK's and a
> broader range of configs (no-vnode, vnode default, compression, etc)
>
> I think this is going to be too heavy...we're taking 500 iterations
> and multiplying that by like 4 or 5?
>
>
>

Re: Tokenization and SAI query syntax

[Andrés de la Peña]

`column = term` is definitively problematic because it creates an ambiguity
when the queried column belongs to the primary key. For some queries we
wouldn't know whether the user wants a primary key query using regular
equality or an index query using the analyzer.

`term_matches(column, term)` seems quite clear and hard to misinterpret,
but it's quite long to write and its implementation will be challenging
since we would need a bunch of special casing around SelectStatement and
functions.

LIKE, MATCHES and CONTAINS could be a bit misleading since they seem to
evoke different behaviours to what they would have.

`column LIKE :term:` seems a bit redundant compared to just using `column :
term`, and we are still introducing a new symbol.

I think I like `column : term` the most, because it's brief, it's similar
to the equivalent Lucene's syntax, and it doesn't seem to clash with other
different meanings that I can think of.

On Mon, 24 Jul 2023 at 13:13, Jonathan Ellis  wrote:

> Hi all,
>
> With phase 1 of SAI wrapping up, I’d like to start the ball rolling on
> aligning around phase 2 features.
>
> In particular, we need to nail down the syntax for doing non-exact string
> matches.  We have a proof of concept that includes full Lucene analyzer and
> filter functionality – just the text transformation pieces, none of the
> storage parts – which is the gold standard in this space.  For example, the
> StandardAnalyzer [1] lowercases all terms and removes stopwords (common
> words like “a”, “is”, “the” that are usually not useful to search
> against).  Lucene also has classes that offer stemming, special case
> handling for email, and many languages besides English [2].
>
> What syntax should we use to express “rows whose analyzed tokens match
> this search term?”
>
> The syntax must be clear that we want to look for this term within the
> column data using the configured index with corresponding query-time
> tokenization and analysis.  This means that the query term is not always a
> substring of the original string!  Besides obvious transformations like
> lowercasing, you have things like PhoneticFilter available as well.
>
> Here are my thoughts on some of the options:
>
> `column = term`.  This is what the POC does today and it’s super confusing
> to overload = to mean something other than exact equality.  I am not a fan.
>
> `column LIKE term` or `column LIKE %term%`. The closest SQL operator, but
> neither the wildcarded nor unwildcarded syntax matches the semantics of
> term-based search.
>
> `column MATCHES term`. I rather like this one, although Mike points out
> that “match” has a meaning in the context of regular expressions that could
> cause confusion here.
>
> `column CONTAINS term`. Contains is used by both Java and Python for
> substring searches, so at least some users will be surprised by term-based
> behavior.
>
> `term_matches(column, term)`. Postgresql FTS makes you use functions like
> this for everything.  It’s pretty clunky, and we would need to make the
> amazingly hairy SelectStatement even hairier to handle “use a function
> result in a predicate” like this.
>
> `column : term`. Inspired by Lucene’s syntax.  I don’t actually hate it.
>
> `column LIKE :term:`. Stick with the LIKE operator but add a new symbol to
> indicate term matching.  Arguably more SQL-ish than a new bare symbol
> operator.
>
> [1]
> https://lucene.apache.org/core/9_7_0/core/org/apache/lucene/analysis/standard/StandardAnalyzer.html
> [2] https://lucene.apache.org/core/9_7_0/analysis/common/index.html
>
> --
> Jonathan Ellis
> co-founder, http://www.datastax.com
> @spyced
>

Re: [VOTE] Release Apache Cassandra 5.0-alpha1 (take3)

[Andrés de la Peña]

+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
>>
>> On Mon, Sep 4, 2023 at 3:26 PM Mick Semb Wever  wrote:
>> >
>> >
>> > Proposing the test build of Cassandra 5.0-alpha1 for release.
>> >
>> > DISCLAIMER, this alpha release does not contain the expected 5.0
>> > features: Vector Search (CEP-30), Transactional Cluster Metadata
>> > (CEP-21) and Accord Transactions (CEP-15).  These features will land
>> > in a later alpha release.
>> >
>> > Please also note that this is an alpha release and what that means,
>> further info at
>> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
>> >
>> > sha1: bc5e3741d475e2e99fd7a10450681fd708431a89
>> > Git: https://github.com/apache/cassandra/tree/5.0-alpha1-tentative
>> > Maven Artifacts:
>> https://repository.apache.org/content/repositories/orgapachecassandra-1316/org/apache/cassandra/cassandra-all/5.0-alpha1/
>> >
>> > The Source and Build Artifacts, and the Debian and RPM packages and
>> repositories, are available here:
>> https://dist.apache.org/repos/dist/dev/cassandra/5.0-alpha1/
>> >
>> > 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]: CHANGES.txt:
>> https://github.com/apache/cassandra/blob/5.0-alpha1-tentative/CHANGES.txt
>> > [2]: NEWS.txt:
>> https://github.com/apache/cassandra/blob/5.0-alpha1-tentative/NEWS.txt
>> >
>>
>

Re: [DISCUSS] Vector type and empty value

[Andrés de la Peña]

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 behavior from server, I wouldn’t be
> shocked to see that other drivers also have their own custom behaviors… so
> not clear how to migrate unless we actually hand a user facing standard per
> type… if all drivers use a “default value” and is consistent, I do think we
> could migrate, but would need to live with this till at least 6.0+
>
> We can only prevent its use in the CQL layer where support isn’t required.
>
>
> +1
>
> On Sep 20, 2023, at 7:38 AM, Benedict  wrote:
>
> Yes, if this is what was meant by empty I agree. It’s nonsensical for most
> types. Apologies for any confusion.
>
> I don’t think we can readily migrate old types away from this however,
> without breaking backwards compatibility. We can only prevent its use in
> the CQL layer where support isn’t required. My understanding was that we
> had at least tried to do this for all non-thrift schemas, but perhaps we
> did not do so thoroughly and now may have some CQL legacy support
> requirements as well.
>
> On 20 Sep 2023, at 15:30, Aleksey Yeshchenko  wrote:
>
> Allowing zero-length byte arrays for most old types is just a legacy from
> Darker Days. It’s a distinct concern from columns being nullable or not.
>
> There are a couple types where this makes sense: strings and blobs. All
> else should not allow this except for backward compatibility reasons. So,
> not for new types.
>
> On 20 Sep 2023, at 00:08, David Capwell  wrote:
>
> When does empty mean null?
>
>
>
> Most types are this way
>
> @Test
> public void nullExample()
> {
> createTable("CREATE TABLE %s (pk int primary key, cuteness int)");
> execute("INSERT INTO %s (pk, cuteness) VALUES (0, ?)", ByteBuffer.wrap(new
> byte[0]));
> Row result = execute("SELECT * FROM %s WHERE pk=0").one();
> if (result.has("cuteness")) System.out.println("Cuteness score: " +
> result.getInt("cuteness"));
> else System.out.println("Cuteness score is undefined");
> }
>
>
> This test will NPE in getInt as the returned BB is seen as “null” for
> int32 type, you can make it “safer” by changing to the following
>
> if (result.has("cuteness")) System.out.println("Cuteness score: " +
> Int32Type.instance.compose(result.getBlob("cuteness")));
>
> Now we get the log "Cuteness score: null”
>
> What’s even better (just found this out) is that client isn’t consistent
> or correct in these cases!
>
> com.datastax.driver.core.Row result = executeNet(ProtocolVersion.CURRENT,
> "SELECT * FROM %s WHERE pk=0").one();
> if (result.getBytesUnsafe("cuteness") != null)
> System.out.println("Cuteness score: " + result.getInt("cuteness"));
> else System.out.println("Cuteness score is undefined”);
>
> This prints "Cuteness score: 0”
>
> So for Cassandra we think the value is “null” but java driver thinks it’s
> 0?
>
> Do we have types where writing an empty value creates a tombstone?
>
>
> Empty does not generate a tombstone for any type, but empty has a similar
> user experience as we return null in both cases (but just found out that
> the drivers may not be consistent with this…)
>
> On Sep 19, 2023, at 3:33 PM, J. D. Jordan 
> wrote:
>
>
> When does empty mean null?  My understanding was that empty is a valid
> value for the types that support it, separate from null (aka a tombstone).
> Do we have types where writing an empty value creates a tombstone?
>
> I agree with David that my preference would be for only blob and string
> like types to support empty. It’s too late for the existing types, but we
> should hold to this going forward. Which is what I think the idea was in
> https://issues.apache.org/jira/browse/CASSANDRA-8951 as well?  That it
> was sad the existing numerics were emptiable, but too late to change, and
> we could correct it for newer types.
>
> On Sep 19, 2023, at 12:12 PM, David Capwell  wrote:
>
> 
>
>
> When we introduced TINYINT and SMALLINT (CASSANDRA-8951) we started making
> types non -emptiable. This approach makes more sense to me as having to
> deal with empty value is error prone in my opinion.
>
>
> I agree it’s confusing, and in the patch I found that different code paths
> didn’t handle things correctly as we have some times (most) that support
> empty bytes, and some that do not…. Empty also has different meaning in
> different code paths; for most it means “null”, and for some other types it
> means “empty”…. To try to make things more clear I added
> org.apache.cassandra.db.marshal.AbstractType#isNull(V,
> org.apache.cassandra.db.marshal.ValueAccessor) to the type system so
> each type can define if empty is null or not.
>
> I also think that it would be good to standardize on one approach to avoid
> confusion.
>
>
> I agree, but also don’t feel it’s a perfect one-size-fits-all thing….
> Let’s s

Re: [VOTE] Accept java-driver

[Andrés de la Peña]

+1

On Wed, 4 Oct 2023 at 05:44, Berenguer Blasi 
wrote:

> +1
> On 4/10/23 4:43, Erick Ramirez wrote:
>
> +1 👍
>
>>

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Andrés de la Peña]

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  wrote:

> Even if it was not formally prescribed as far as I understand, we have
> been following the "only merge on Green CI" custom as much as possible for
> the past several years. Is the proposal to relax this rule for 5.0?
>
> On Tue, Oct 31, 2023 at 1:02 PM Jeremiah Jordan 
> wrote:
>
>> You are free to argue validity.  I am just stating what I see on the
>> mailing list and in the wiki.  We had a vote which was called passing and
>> was not contested at that time.  The vote was on a process which includes
>> as #3 in the list:
>>
>>
>>1. Before a merge, a committer needs either a non-regressing (i.e. no
>>new failures) run of circleci with the required test suites (TBD; see
>>below) or of ci-cassandra.
>>   1. Non-regressing is defined here as "Doesn't introduce any new
>>   test failures; any new failures in CI are clearly not attributable to 
>> this
>>   diff"
>>   2. (NEW) After merging tickets, ci-cassandra runs against the SHA
>>   and the author gets an advisory update on the related JIRA for any new
>>   errors on CI. The author of the ticket will take point on triaging 
>> this new
>>   failure and either fixing (if clearly reproducible or related to their
>>   work) or opening a JIRA for the intermittent failure and linking it in
>>   butler (https://butler.cassandra.apache.org/#/)
>>
>>
>> Which clearly says that before merge we ensure there are no known new
>> regressions to CI.
>>
>> The allowance for releases without CI being green, and merges without the
>> CI being completely green are from the fact that our trunk CI has rarely
>> been completely green, so we allow merging things which do not introduce
>> NEW regressions, and we allow releases with known regressions that are
>> deemed acceptable.
>>
>> We can indeed always vote to override it, and if it comes to that we can
>> consider that as an option.
>>
>> -Jeremiah
>>
>> On Oct 31, 2023 at 11:41:29 AM, Benedict  wrote:
>>
>>> That vote thread also did not reach the threshold; it was incorrectly
>>> counted, as committer votes are not binding for procedural changes. I
>>> counted at most 8 PMC +1 votes.
>>>
>>> The focus of that thread was also clearly GA releases and merges on such
>>> branches, since there was a focus on releases being failure-free. But this
>>> predates the more general release lifecycle vote that allows for alphas to
>>> have failing tests - which logically would be impossible if nothing were
>>> merged with failing or flaky tests.
>>>
>>> Either way, the vote and discussion specifically allow for this to be
>>> overridden.
>>>
>>> 🤷‍♀️
>>>
>>> On 31 Oct 2023, at 16:29, Jeremiah Jordan 
>>> wrote:
>>>
>>> 
>>> I never said there was a need for green CI for alpha.  We do have a
>>> requirement for not merging things to trunk that have known regressions in
>>> CI.
>>> Vote here:
>>> https://lists.apache.org/thread/j34mrgcy9wrtn04nwwymgm6893h0xwo9
>>>
>>>
>>>
>>> On Oct 31, 2023 at 3:23:48 AM, Benedict  wrote:
>>>
 There is no requirement for green CI on alpha. We voted last year to
 require running all tests before commit and to require green CI for beta
 releases. This vote was invalid because it didn’t reach the vote floor for
 a procedural change but anyway is not inconsistent with knowingly and
 selectively merging work without green CI.

 If we reach the summit we should take a look at the state of the PRs
 and make a decision about if they are alpha quality; if so, and we want a
 release, we should simply merge it and release. Making up a new release
 type when the work meets alpha standard to avoid an arbitrary and not
 mandated commit bar seems the definition of silly.

 On 31 Oct 2023, at 04:34, J. D. Jordan 
 wrote:

 
 That is my understanding as well. If the TCM and Accord based on TCM
 branches are ready to commit by ~12/1 we can cut a 5.1 branch and then a
 5.1-alpha release.
 Where “ready to commit” means our usual things of two committer +1 and
 green CI etc.

 If we are not ready to commit then I propose that as long as everything
 in the accord+tcm Apache repo branch has had two committer +1’s, but maybe
 people are still working on fixes for getting CI green or similar, we cut a
 5.1-preview  build from the feature branch to vote on with known issues
 documented.  This would not be the preferred path, but would be a way to
 have a voted on release for summit.

 -Jeremiah

 On Oct 30, 2023, at 5:59 PM, Mick Semb Wever  wrote:

 

 Hoping we can get clarity on this.

 The proposal was, once TCM and Accord 

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

[Andrés de la Peña]

Congrats Francisco!

On Wed, 29 Nov 2023 at 11:37, Benjamin Lerer  wrote:

> Congratulations!!! Well deserved!
>
> Le mer. 29 nov. 2023 à 07:31, Berenguer Blasi 
> a écrit :
>
>> Welcome!
>> On 29/11/23 2:24, guo Maxwell wrote:
>>
>> Congrats!
>>
>> Jacek Lewandowski  于2023年11月29日周三 06:16写道：
>>
>>> Congrats!!!
>>>
>>> wt., 28 lis 2023, 23:08 użytkownik Abe Ratnofsky  napisał:
>>>
 Congrats Francisco!

 > On Nov 28, 2023, at 1:56 PM, C. Scott Andreas 
 wrote:
 >
 > Congratulations, Francisco!
 >
 > - Scott
 >
 >> On Nov 28, 2023, at 10:53 AM, Dinesh Joshi 
 wrote:
 >>
 >> The PMC members are pleased to announce that Francisco Guerrero
 Hernandez has accepted
 >> the invitation to become committer today.
 >>
 >> Congratulations and welcome!
 >>
 >> The Apache Cassandra PMC members

Re: Welcome Mike Adamson as Cassandra committer

[Andrés de la Peña]

Congrats Mike!

On Fri, 8 Dec 2023 at 14:53, Jeremiah Jordan 
wrote:

> Congrats Mike!  Thanks for all your work on SAI and Vector index.  Well
> deserved!
>
> On Dec 8, 2023 at 8:52:07 AM, Brandon Williams  wrote:
>
>> Congratulations Mike!
>>
>> Kind Regards,
>> Brandon
>>
>> On Fri, Dec 8, 2023 at 8:41 AM Benjamin Lerer  wrote:
>>
>>
>> The PMC members are pleased to announce that Mike Adamson has accepted
>>
>> the invitation to become committer.
>>
>>
>> Thanks a lot, Mike, for everything you have done for the project.
>>
>>
>> Congratulations and welcome
>>
>>
>> The Apache Cassandra PMC members
>>
>>

Re: Welcome Maxim Muzafarov as Cassandra Committer

[Andrés de la Peña]

Congrats, Maxim!

On Tue, 9 Jan 2024 at 03:45, guo Maxwell  wrote:

> Congratulations, Maxim!
>
> Francisco Guerrero  于2024年1月9日周二 09:00写道：
>
>> Congratulations, Maxim! Well deserved!
>>
>> On 2024/01/08 18:19:04 Josh McKenzie wrote:
>> > The Apache Cassandra PMC is pleased to announce that Maxim Muzafarov
>> has accepted
>> > the invitation to become a committer.
>> >
>> > Thanks for all the hard work and collaboration on the project thus far,
>> and we're all looking forward to working more with you in the future.
>> Congratulations and welcome!
>> >
>> > The Apache Cassandra PMC members
>> >
>> >
>>
>

Warn about SASI usage and allow to disable them

[Andrés de la Peña]

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 problems described in CASSANDRA-8272.
There is a pending-review patch addressing the problem for regular 2i.
However, the proposed solution is based on indexing tombstones. SASI
doesn't index tombstones, so it wouldn't be enterely trivial to extend the
approach to SASI.
- Probably insufficient testing. As far as I know, we don't have a single
dtest for SASI nor tests dealing with large SSTables.

Similarly to what CASSANDRA-13959 did with materialized views,
CASSANDRA-14866 aims to throw a native protocol warning about SASI
experimental state, and to add a config property to disable them. Perhaps
this property could be disabled by default in trunk. This should raise
awareness about SASI maturity until we let them in a more stable state.

The purpose for this thread is discussing whether we want to add this
warning, the config property and, more controversially, if we want to set
SASI as disabled by default in trunk.

WDYT?

Re: Warn about SASI usage and allow to disable them

[Andrés de la Peña]

I mean disabling the creation of new SASI indices with CREATE INDEX
statement, the existing indexes would continue working. The CQL client
warning will be thrown with that creation statement as well (if they are
enabled).

On Mon, 14 Jan 2019 at 20:18, Jeff Jirsa  wrote:

> When we say disable, 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 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 problems described in
> CASSANDRA-8272.
> > There is a pending-review patch addressing the problem for regular 2i.
> > However, the proposed solution is based on indexing tombstones. SASI
> > doesn't index tombstones, so it wouldn't be enterely trivial to extend
> the
> > approach to SASI.
> > - Probably insufficient testing. As far as I know, we don't have a single
> > dtest for SASI nor tests dealing with large SSTables.
> >
> > Similarly to what CASSANDRA-13959 did with materialized views,
> > CASSANDRA-14866 aims to throw a native protocol warning about SASI
> > experimental state, and to add a config property to disable them. Perhaps
> > this property could be disabled by default in trunk. This should raise
> > awareness about SASI maturity until we let them in a more stable state.
> >
> > The purpose for this thread is discussing whether we want to add this
> > warning, the config property and, more controversially, if we want to set
> > SASI as disabled by default in trunk.
> >
> > WDYT?
> >
>

Re: Warn about SASI usage and allow to disable them

[Andrés de la Peña]

Thanks for the feedback.
It seems we agree to the config property, disabled by default in trunk.
Regarding the warning, we might add it at least in 3.11, since for that
version the property to enable SASI is going to be present but not disabled
by default. WDYT?

On Tue, 15 Jan 2019 at 11:24, Benjamin Lerer 
wrote:

>  +1 on config. +1 on disabling by default
>
> On Tue, Jan 15, 2019 at 6:51 AM Jeff Jirsa  wrote:
>
> > +1 on config
> > -0 on warning
> > -0 on disabling by default
> >
> >
> > --
> > Jeff Jirsa
> >
> >
> > > On Jan 14, 2019, at 9:22 PM, Taylor Cressy 
> > wrote:
> > >
> > > +1 on config. +1 on disabling.
> > >
> > > +1 on applying it to materialized views as well.
> > >
> > >> On Jan 14, 2019, at 17:29, Joshua McKenzie 
> > wrote:
> > >>
> > >> +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:28 PM Andrés de la Peña <
> > a.penya.gar...@gmail.com>
> > >> wrote:
> > >>
> > >>> I mean disabling the creation of new SASI indices with CREATE INDEX
> > >>> statement, the existing indexes would continue working. The CQL
> client
> > >>> warning will be thrown with that creation statement as well (if they
> > are
> > >>> enabled).
> > >>>
> > >>>> On Mon, 14 Jan 2019 at 20:18, Jeff Jirsa  wrote:
> > >>>>
> > >>>> When we say disable, 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 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 problems described in
> > >>>> CASSANDRA-8272.
> > >>>>> There is a pending-review patch addressing the problem for regular
> > 2i.
> > >>>>> However, the proposed solution is based on indexing tombstones.
> SASI
> > >>>>> doesn't index tombstones, so it wouldn't be enterely trivial to
> > extend
> > >>>> the
> > >>>>> approach to SASI.
> > >>>>> - Probably insufficient testing. As far as I know, we don't have a
> > >>> single
> > >>>>> dtest for SASI nor tests dealing with large SSTables.
> > >>>>>
> > >>>>> Similarly to what CASSANDRA-13959 did with materialized views,
> > >>>>> CASSANDRA-14866 aims to throw a native protocol warning about SASI
> > >>>>> experimental state, and to add a config property to disable them.
> > >>> Perhaps
> > >>>>> this property could be disabled by default in trunk. This should
> > raise
> > >>>>> awareness about SASI maturity until we let them in a more stable
> > state.
> > >>>>>
> > >>>>> The purpose for this thread is discussing whether we want to add
> this
> > >>>>> warning, the config property and, more controversially, if we want
> to
> > >>> set
> > >>>>> SASI as disabled by default in trunk.
> > >>>>>
> > >>>>> WDYT?
> > >>>>>
> > >>>>
> > >>>
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: Warn about SASI usage and allow to disable them

[Andrés de la Peña]

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:

- CQL native protocol warning on create SASI index: three +1s, one +0 and
two -0s
- Config property to disable new SASI creation: ten +1s
- New SASI creation disabled by default in trunk: nine +1s and one -0
- New MV creation disabled by default in trunk: three +1s

If there are no objections, I'll update the patch by the end of next week.

On Mon, 21 Jan 2019 at 19:26, Paulo Motta  wrote:

> +1 to enable_sasi_indexes flag
> +1 to disabling experimental features by default on 4.0 (SASI and MVs,
> transient replication already disabled)
>
> Regarding the warning on creation of SASI indexes, I think that's a
> user-level warning complimentary to the flag, which is targeted to admins,
> so +1. If people are bothered by this, we could add another flag to disable
> warnings on experimental features, which would be applied to both this and
> MV creation warning (and any other future experimental feature).
>
> I think the warning should be "SASI indexes are experimental and are not
> recommended for production use.", similar to the MV warning added on
> CASSANDRA-13959.
>
> We should open a doc ticket to list limitations of experimental features
> (MVs, SASI, transient replication), but this should probably be out of the
> scope of CASSANDRA-14866. Once we have this doc, we can maybe amend the
> warning to include a link to the doc.
>
> Now that the number of experimental feature flags is growing we should
> perhaps unify all flags in a "experimental features" section on
> cassandra.yaml to allow easily locating them - and a pointer to the
> limitations doc once we have it.
>
> Em qua, 16 de jan de 2019 às 20:18, sankalp kohli 
> escreveu:
>
> > If we want to put a warning, we should list in a doc all the open issues
> it
> > has along with explanation of how it can impact. We have a few in the
> first
> > email of this thread but we should put it in a doc for people to know
> what
> > are the issues and if they want to take that risk.
> >
> >
> >
> > On Wed, Jan 16, 2019 at 3:14 PM Brandon Williams 
> wrote:
> >
> > > Which, if I'm not mistaken, is the goal here?
> > >
> > > On Wed, Jan 16, 2019 at 5:12 PM Jeff Jirsa  wrote:
> > >
> > > > The cost is in how many users you scare away
> > > >
> > > > --
> > > > Jeff Jirsa
> > > >
> > > >
> > > > > On Jan 16, 2019, at 2:34 PM, Brandon Williams 
> > > wrote:
> > > > >
> > > > > Also it costs us nothing to add it.
> > > > >
> > > > >> On Wed, Jan 16, 2019 at 4:29 PM Jonathan Haddad <
> j...@jonhaddad.com>
> > > > wrote:
> > > > >>
> > > > >> I'm +1 on the warning for two reasons.
> > > > >>
> > > > >>> A cqlsh warning only applies to those that create the sasi via
> > cqlsh.
> > > > >>
> > > > >> 1. When people are creating their schemas in development, this is
> > > > usually
> > > > >> the first step.  You use the REPL to figure out what you need,
> then
> > > you
> > > > >> copy your schema somewhere else.  The warning here should prevent
> a
> > > lot
> > > > of
> > > > >> folks from making a serious mistake.
> > > > >>
> > > > >> 2. It's consistent with how we warn when people try to use
> > > materialized
> > > > >> views.
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>> On Wed, Jan 16, 2019 at 2:15 PM Mick Semb Wever 
> > > > wrote:
> > > > >>>
> > > > >>> Regarding the warning, we might add it at least in 3.11, since
> for
> > > that
> > > > >>> version the property to enable SASI is going to be present but
> not
> > > > >> disabled
> > > > >>> by default. WDYT?
> > > > >>>
> > > > >>>
> > > > >>> I'm  -0 on this.
> > > > >>>
> > > > >>> A single line warning in the logs on the sasi creation won't be
> > > noticed
> > > > >> by
> > > > >>> many users.
> > > > >>> A cqlsh warning only applies to those that create the sasi via
> > cqlsh.
> > > > >>> And we're not talking about patching client drivers to generate a
> > > > warning
> > > > >>> there.
> > > > >>>
> > > > >>> So I'd be happy with a yaml comment on the config flag explaining
> > > that
> > > > >>> it's a beta feature and that users should check open tickets and
> > > > >> understand
> > > > >>> current limitations on sasi before using them.
> > > > >>>
> > > > >>> regards,
> > > > >>> Mick
> > > > >>>
> > > > >>>
> > -
> > > > >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > >>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > > >>>
> > > > >>>
> > > > >>
> > > > >> --
> > > > >> Jon Haddad
> > > > >> http://www.rustyrazorblade.com
> > > > >> twitter: rustyrazorblade
> > > > >>
> > > >
> > > > -
> > > > To unsubscribe, e-mai

Re: Discussion: addition to CEP guide

[Andrés de la Peña]

+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
> >>
> >> On Wed, Apr 22, 2020 at 11:53 AM Joshua McKenzie 
> >> wrote:
> >>
> 
>  Maybe put it high up the list, e.g. after Description of Approach?
> >>>
> >>> Really great point. Definitely not the lowest priority item.
> >>>
> >>> I'll leave this thread open for another 24 or 48 for feedback; if
> >>> noncontroversial I'll edit then.
> >>>
> >>> On Wed, Apr 22, 2020 at 1:45 PM Scott Andreas 
> >>> wrote:
> >>>
>  Sounds good to me as well, thanks for suggesting.
> 
>  
>  From: Jon Haddad 
>  Sent: Wednesday, April 22, 2020 9:54 AM
>  To: dev@cassandra.apache.org
>  Subject: Re: Discussion: addition to CEP guide
> 
>  Great idea Josh, +1
> 
>  On Wed, Apr 22, 2020 at 9:47 AM Benedict Elliott Smith <
>  bened...@apache.org>
>  wrote:
> 
> > +1.  This might also serve to produce specific points of discussion
>  around
> > the topic as the CEP progresses.
> >
> > Maybe put it high up the list, e.g. after Description of Approach?
> >
> >
> >
> > On 22/04/2020, 17:40, "Joshua McKenzie" 
> >> wrote:
> >
> >Link to CEP guide:
> >
> >
> 
> >>>
> >>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201
> >
> >Currently the CEP guide reads:
> >---
> >
> >*A CEP should contain the following sections: *
> >
> >   -
> >
> >   *Scope,*
> >   -
> >
> >   *Goals (and non-goals),*
> >   -
> >
> >   *Description of Approach,*
> >   -
> >
> >   *Timeline,*
> >   -
> >
> >   *Mailing list / Slack channels,*
> >   -
> >
> >   *Related JIRA tickets.*
> >
> >--
> >What does everyone think about adding another bullet item as
> >>> follows:
> >
> >   - A test plan covering performance, correctness, failure, and
> > boundary
> >   conditions (as applicable)
> >
> >--
> >Or some variation thereof. I personally think it's worth calling
> >>> out
> > "We
> >should think about and discuss how we're going to test something
>  from a
> >high level collectively before we dive into it", since we've had
> >>> some
> > pain
> >in the past in that area.
> >
> >Thoughts?
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>  For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
> 
> >>>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSSION] Flaky tests

[Andrés de la Peña]

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 test a few dozen times is probably
going to be quicker, safer and cheaper than re-running the entire suite.

That's not going to absolutely probe that a test is not flaky in every
environment, but probably it would reduce the risk of introducing new flaky
tests.

On Thu, 28 May 2020 at 22:26, David Capwell 
wrote:

> > - No flaky tests according to Jenkins or CircleCI? Also, some people run
> > the free tier, others take advantage of premium CircleCI. What should be
> > the framework?
>
> It would be good to have a common understanding of this; my current mental
> model is
>
> 1) Jenkins
> 2) Circle CI Free tear unit tests (including in-jvm dtests)
> 3) Circle CI paid tear python dtest
>
> > - "ignored in exceptional cases" - examples?
>
>
> I personally don’t classify a test as flaky if the CI environment is at
> fault, simple example could be bad disk causing tests to fail.  In this
> example, actions should be taken to fix the CI environment, but if the
> tests pass in another environment I am fine moving on and not blocking a
> release.
>
> > I got the impression that canonical suite (in this case Jenkins) might
> be the right direction to follow.
>
>
> I agree that Jenkins must be a source of input, but don’t think it should
> be the only one at this moment; currently Circle CI produces more builds of
> Cassandra than Jenkins, so ignoring tests failures there causes a more
> unstable environment for development and hide the fact that Jenkins will
> also see the issue.  There are also gaps with Jenkins coverage which hide
> things such as lack of java 11 support and that tests fail more often on
> java 11.
>
> > But also, sometimes I feel in many cases CircleCI could provide input
> worth tracking but less likely to be product flakes
>
>
> Since Circle CI runs more builds than Jenkins, we are more likely to see
> flaky tests there than Jenkins.
>
> > Not to mention flaky tests on Mac running with two cores... Yes, this is
> sometimes the only way to reproduce some of the reported tests' issues...
>
>
> I am not aware of anyone opening JIRAs based off this, only using this
> method to reproduce issues found in CI.  I started using this method to
> help quickly reproduce race condition bugs found in CI such as nodetool
> reporting repairs as success when they were actually failed, and one case
> you are working on where preview repair conflicts with a non-committed IR
> participant even though we reported commit to users (both cases are valid
> bugs found in CI).
>
> > So my idea was to suggest to start tracking an exact Jenkins report maybe
>
>
> Better visibility is great!  Mick has been setup Slack/Email
> notifications, but maybe a summary in the 4.0 report would be great to
> enhance visibility to all?
>
> > checked but potentially to be able to leave it for Beta in case we don't
> feel it shows a product defect
>
> Based off
> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle <
> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle>
> flaky tests block beta releases, so need to happen before then.  What do
> you mean by “leave it for Beta”? Right now we label alpha but don’t block
> alpha releases on flaky tests, given this I don’t follow this statement,
> could you explain more?
>
> >> At least for me, what I learned in the past is we'd drive to a green
> test
> >> board and immediately transition it as a milestone, so flaky tests would
> >> reappear like a disappointing game of whack-a-mole. They seem
> frustratingly
> >> ever-present.
>
> How I see the document, all definitions/expectations from previous phases
> hold true for later stages. Right now the document says we can not cut
> beta1 until flaky tests are resolved, but this would also mean beta2+, rc+,
> etc; how I internalize this is that pre-beta1+, flaky tests are not
> allowed, so we don’t immediately transition away from this.
>
> One trend I have noticed in Cassandra is a lack of trust in tests caused
> by the fact that unrelated failing builds are common; what then happens is
> the author/reviewer ignore the new failing test, write it off as a flaky
> test, commit, and cause more tests to fail. Since testing can be skipped
> pre-commit, and failing tests can be ignored, it puts us in a state that
> new regressions pop up after commit; by having the flaky-tests as a guard
> against release it causes a forcing function to stay stable as long as
> possible.
>
> >> Default posture to label fix version as beta
>
> Can you explain what you mean by this? Currently we don’t block alpha
> releases on flaky tests even though they are marked alpha, are you
> proposing we don’t block beta releases on flaky tests o

Re: [VOTE] Project governance wiki doc

[Andrés de la Peña]

+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
> > >
> > >
> > > On 17 June 2020 at 12:40:38, Sam Tunnicliffe (s...@beobal.com) wrote:
> > > > +1 (binding)
> > > >
> > > > > On 17 Jun 2020, at 09:11, Jorge Bay Gondra wrote:
> > > > >
> > > > > +1 nb
> > > > >
> > > > > On Wed, Jun 17, 2020 at 7:41 AM Mick Semb Wever wrote:
> > > > >
> > > > >> +1 (binding)
> > > > >>
> > > > >> On Tue, 16 Jun 2020 at 18:19, Joshua McKenzie
> > > > >> wrote:
> > > > >>
> > > > >>> Added unratified draft to the wiki here:
> > > > >>>
> > > > >>>
> > > > >>
> > >
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> > > > >>>
> > > > >>> I propose the following:
> > > > >>>
> > > > >>> 1. We leave the vote open for 1 week (close at end of day
> 6/23/20)
> > > > >>> unless there's a lot of feedback on the wiki we didn't get on
> gdoc
> > > > >>> 2. pmc votes are considered binding
> > > > >>> 3. committer and community votes are considered advisory /
> > > non-binding
> > > > >>>
> > > > >>> Any objections / revisions to the above?
> > > > >>>
> > > > >>> Thanks!
> > > > >>>
> > > > >>> ~Josh
> > > > >>>
> > > > >>
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >
> > > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >
>

Re: [VOTE] Project governance wiki doc (take 2)

[Andrés de la Peña]

+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 simple majority of this electorate becomes the low-watermark for votes
> > in favour necessary to pass a motion, with new PMC members added to the
> > calculation."
> >
> > This previously read "super majority". We have lowered the low water mark
> > to "simple majority" to balance strong consensus against risk of stall
> due
> > to low participation.
> >
> >
> >- Vote will run through 6/24/20
> >- pmc votes considered binding
> >- simple majority of binding participants passes the vote
> >- committer and community votes considered advisory
> >
> > Lastly, I propose we take the count of pmc votes in this thread as our
> > initial roll call count for electorate numbers and low watermark
> > calculation on subsequent votes.
> >
> > Thanks again everyone (and specifically Benedict and Jon) for the time
> and
> > collaboration on this.
> >
> > ~Josh
>
>
>
> --
> Eric Evans
> john.eric.ev...@gmail.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Release Apache Cassandra 4.0-beta1

[Andrés de la Peña]

+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 injection for map, set, counter, batch,
> and
> > > LWT passed.
> > > https://github.com/scalar-labs/scalar-jepsen
> > >
> > > 2020年7月15日(水) 8:06 Mick Semb Wever :
> > >
> > > > Proposing the test build of Cassandra 4.0-beta1 for release.
> > > >
> > > > sha1: 5e767711360ecc4bc05a7cd219f0e680bfada004
> > > > Git:
> > > >
> > > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta1-tentative
> > > > Maven Artifacts:
> > > >
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1210/org/apache/cassandra/cassandra-all/4.0-beta1/
> > > >
> > > > The Source and Build Artifacts, and the Debian and RPM packages and
> > > > repositories, are available here:
> > > > https://dist.apache.org/repos/dist/dev/cassandra/4.0-beta1/
> > > >
> > > > 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
> > > -1s.
> > > >
> > > > Eventual publishing and announcement of the 4.0-beta1 release will be
> > > > coordinated, as described in
> > > >
> > > >
> > >
> >
> https://lists.apache.org/thread.html/r537fe799e7d5e6d72ac791fdbe9098ef0344c55400c7f68ff65abe51%40%3Cdev.cassandra.apache.org%3E
> > > >
> > > > [1]: CHANGES.txt:
> > > >
> > > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-beta1-tentative
> > > > [2]: NEWS.txt:
> > > >
> > > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta1-tentative
> > > >
> > >
> >
>
>
> --
> http://twitter.com/tjake
>

Re: [VOTE] Release Apache Cassandra 4.0-beta1 (take2)

[Andrés de la Peñ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 test build of Cassandra 4.0-beta1 for release.
> >
> > sha1: 972da6fcffa87b3a1684362a2bab97db853372d8
> > Git:
> >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta1-tentative
> > Maven Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1211/org/apache/cassandra/cassandra-all/4.0-beta1/
> >
> > The Source and Build Artifacts, and the Debian and RPM packages and
> > repositories, are available here:
> > https://dist.apache.org/repos/dist/dev/cassandra/4.0-beta1/
> >
> > The vote will be open for 60 hours (longer if needed). I've taken 12
> hours
> > off the normal 72 hours and this follows closely after the initial
> > 4.0-beta1 vote. 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 -1s.
> >
> > Eventual publishing and announcement of the 4.0-beta1 release will be
> > coordinated, as described in
> >
> >
> https://lists.apache.org/thread.html/r537fe799e7d5e6d72ac791fdbe9098ef0344c55400c7f68ff65abe51%40%3Cdev.cassandra.apache.org%3E
> >
> > [1]: CHANGES.txt:
> >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-beta1-tentative
> > [2]: NEWS.txt:
> >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta1-tentative
> >
>

Re: [VOTE] Release dtest-api 0.0.6

[Andrés de la Peña]

+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 Brandon Williams  wrote:
>
> > +1
> >
> > On Thu, Oct 8, 2020 at 3:20 AM Oleksandr Petrov
> >  wrote:
> > >
> > > Proposing the test build of in-jvm dtest API 0.0.6 for release.
> > >
> > > Repository:
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.6
> > >
> > > Candidate SHA:
> > >
> >
> https://github.com/apache/cassandra-in-jvm-dtest-api/commit/9efeb731b6ff4036fa822b0282b27d273975cd6fTT
> > > tagged with 0.0.6
> > > Artifact:
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1220/org/apache/cassandra/dtest-api/0.0.6/
> > >
> > > Key signature: 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C
> > >
> > > Changes since last release:
> > >
> > >   * CASSANDRA-16148: Add IInstance#getReleaseVersionString
> > >
> > > The vote will be open for 24 hours. 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.
> > >
> > > -- Alex
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Release Apache Cassandra 3.0.23

[Andrés de la Peña]

+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 -1's.
>
>
> +1 (binding)
>
>
> Test Results:  https://ci-cassandra.apache.org/job/Cassandra-3.0/33/
>
> Checked signatures, checksums, source build, and artefacts install and run.
>
> Remaining issues:
>  - lib/ directory (binary files) bundled into the src artefact
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Release Apache Cassandra 4.0-beta3

[Andrés de la Peña]

+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 and no -1's.
> >
>
>
> +1 (binding)
>
>
> Test Results:  https://ci-cassandra.apache.org/job/Cassandra-trunk/105/
>
> Checked signatures, checksums, source build, and artefacts install and run.
>
> Remaining issues:
>  - lib/ directory (binary files) bundled into the src artefact
>

Re: [VOTE] Release Apache Cassandra 2.2.19

[Andrés de la Peña]

+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's.
>
>
> +1 (binding)
>
>
> Test Results:  https://ci-cassandra.apache.org/job/Cassandra-2.2/20/
>
> Checked signatures, checksums, source build, and artefacts install and run.
>
> Remaining issues:
>  - lib/ directory (binary files) bundled into the src artefact
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Release Apache Cassandra 3.11.9

[Andrés de la Peña]

+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) bundled into the src artefact
>

Re: Welcome Jordan West, David Capwell, Zhao Yang and Ekaterina Dimitrova as Cassandra committers

[Andrés de la Peña]

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 Wed, Dec 16, 2020 at 2:53 PM Joshua McKenzie 
> > wrote:
> >
> > > Congrats everyone! Great to see new folks joining the project.
> > >
> > > On Wed, Dec 16, 2020 at 3:55 PM Dinesh Joshi 
> wrote:
> > >
> > > > Congratulations everyone!
> > > >
> > > > Dinesh
> > > >
> > > > > On Dec 16, 2020, at 8:55 AM, Benjamin Lerer <
> > > benjamin.le...@datastax.com>
> > > > wrote:
> > > > >
> > > > > The PMC's members are pleased to announce that Jordan West, David
> > > > Capwell,
> > > > > Zhao Yang and Ekaterina Dimitrova have accepted the invitations to
> > > become
> > > > > committers this year.
> > > > >
> > > > > Jordan West accepted the invitation in April
> > > > > David Capwell accepted the invitation in July
> > > > > Zhao Yang accepted the invitation in September
> > > > > Ekaterina Dimitrova accepted the invitation in December
> > > > >
> > > > > Thanks a lot for everything you have done.
> > > > >
> > > > > Congratulations and welcome
> > > > >
> > > > > The Apache Cassandra PMC members
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >
> > > >
> > >
> >
>

Re: Welcome Paulo Motta as Cassandra PMC member

[Andrés de la Peña]

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 Dimitrova  >
> > wrote:
> >
> > > Congrats! Well done!
> > >
> > > On Tue, 9 Feb 2021 at 11:02, J. D. Jordan 
> > > wrote:
> > >
> > > > Congrats Paulo! A great addition to the PMC.
> > > >
> > > > > On Feb 9, 2021, at 9:59 AM, Jonathan Ellis 
> > wrote:
> > > > >
> > > > > Congratulations, Paulo!  Well deserved.
> > > > >
> > > > >> On Tue, Feb 9, 2021 at 9:54 AM Benjamin Lerer <
> > > > benjamin.le...@datastax.com>
> > > > >> wrote:
> > > > >>
> > > > >> The PMC's members are pleased to announce that Paulo Motta has
> > > accepted
> > > > >> the invitation to become a PMC member yesterday.
> > > > >>
> > > > >> Thanks a lot, Paulo, for everything you have done for the project
> > all
> > > > these
> > > > >> years.
> > > > >>
> > > > >> Congratulations and welcome
> > > > >>
> > > > >> The Apache Cassandra PMC members
> > > > >>
> > > > >
> > > > >
> > > > > --
> > > > > Jonathan Ellis
> > > > > co-founder, http://www.datastax.com
> > > > > @spyced
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >
> > > >
> > >
> >
>

Re: Welcome Berenguer Blasi as Cassandra committer

[Andrés de la Peña]

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
> > accepted the invitation to become committer today.
> >
> > Thanks a lot,  Berenguer,  for all the work you have done!
> >
> > Congratulations and welcome
> >
> > The Apache Cassandra PMC members
> >
>

Re: [VOTE] Release Apache Cassandra 4.0-rc1

[Andrés de la Peña]

+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:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc1-tentative
> > Maven Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1234/org/apache/cassandra/cassandra-all/4.0-rc1/
> >
> > The Source and Build Artifacts, and the Debian and RPM packages and
> > repositories, are available here:
> > https://dist.apache.org/repos/dist/dev/cassandra/4.0-rc1/
> >
> > 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.
> >
> > Known issues with this release, that are planned to be fixed in 4.0-rc2,
> are
> >  - four files were missing copyright headers,
> >  - LICENSE and NOTICE contain additional unneeded information,
> >  - jar files under lib/ in the source artefact.
> >
> > These issues are actively being worked on, along with our expectations
> that
> > the ASF makes the policy around them more explicit so it is clear exactly
> > what is required of us.
> >
> >
> > [1]: CHANGES.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-rc1-tentative
> > [2]: NEWS.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-rc1-tentative
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Release Apache Cassandra 4.0-rc1 (take2)

[Andrés de la Peña]

+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:
> > > > +1
> > > >
> > > >> On Apr 21, 2021, at 2:25 PM, Scott Andreas 
> > > wrote:
> > > >>
> > > >> +1nb, thank you!
> > > >>
> > > >> 
> > > >> From: Ekaterina Dimitrova 
> > > >> Sent: Wednesday, April 21, 2021 12:23 PM
> > > >> To: dev@cassandra.apache.org
> > > >> Subject: Re: [VOTE] Release Apache Cassandra 4.0-rc1 (take2)
> > > >>
> > > >> +1 and thanks everyone for all the hard work
> > > >>
> > > >> Checked:
> > > >> - gpg signatures
> > > >> - sha checksums
> > > >> - binary convenience artifact runs
> > > >> - src convenience artifacts builds with one command, and runs
> > > >> - deb and rpm install and run
> > > >>
> > > >>> On Wed, 21 Apr 2021 at 14:57, Michael 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
> > > >>>
> > > >>>
> > > >>>
> -
> > > >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > >>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >>>
> > > >>>
> > > >>
> -
> > > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >>
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >
>

Re: Welcome Stefan Miklosovic as Cassandra committer

[Andrés de la Peña]

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 17:17, Ben Bromhead 
> >> escreveu:
> >>
> >>> Congrats mate!
> >>>
> >>> On Tue, May 4, 2021 at 4:20 AM Scott Andreas 
> >> wrote:
>  Congratulations, Štefan!
> 
>  
>  From: David Capwell 
>  Sent: Monday, May 3, 2021 10:53 AM
>  To: dev@cassandra.apache.org
>  Subject: Re: Welcome Stefan Miklosovic as Cassandra committer
> 
>  Congrats!
> 
> > On May 3, 2021, at 9:47 AM, Ekaterina Dimitrova <
> >> e.dimitr...@gmail.com
>  wrote:
> > Congrat Stefan! Well done!!
> >
> > On Mon, 3 May 2021 at 11:49, J. D. Jordan   wrote:
> >> Well deserved!  Congrats Stefan.
> >>
> >>> On May 3, 2021, at 10:46 AM, Sumanth Pasupuleti <
> >> sumanth.pasupuleti...@gmail.com> wrote:
> >>> Congratulations Stefan!!
> >>>
>  On Mon, May 3, 2021 at 8:41 AM Brandon Williams  >> wrote:
>  Congratulations, Stefan!
> 
> > On Mon, May 3, 2021 at 10:38 AM Benjamin Lerer <
> >> b.le...@gmail.com>
> >> wrote:
> > The PMC's members are pleased to announce that Stefan Miklosovic
> >>> has
> > accepted the invitation to become committer last Wednesday.
> >
> > Thanks a lot, Stefan,  for all your contributions!
> >
> > Congratulations and welcome
> >
> > The Apache Cassandra PMC members
> 
> >>> -
>  To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>  For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
> 
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>
> >>
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>  For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
>  --
> >>> Ben Bromhead
> >>>
> >>> Instaclustr | www.instaclustr.com | @instaclustr
> >>>  | +64 27 383 8975
> >>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

CircleCI job to run some tests repeatedly

[Andrés de la Peña]

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, such as unit tests or JVM dtests, can be run with the
"repeated_utest" job, while Python dtests can be run with the
"repeated_dtest" job. The names of the tests to be run, the number of
repetitions, etc. are set in env vars in the CircleCI config file. There
are more details about these vars in the documentation:
https://github.com/apache/cassandra/blob/trunk/doc/source/development/testing.rst#circleci

For example, this job runs the StreamingMetricsTest JVM dtest 200 times in
~5min, hitting 23 failures:
https://app.circleci.com/pipelines/github/adelapena/cassandra/388/workflows/034b59a0-11ed-469f-bb24-d13922f8a942/jobs/3346

Regards,

Re: Welcome Caleb Rackliffe as Cassandra committer

[Andrés de la Peña]

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 Fri, May 14, 2021 at 9:12 AM David Capwell  >
> > wrote:
> >
> > > Congrats!
> > >
> > > > On May 14, 2021, at 8:52 AM, Charles Cao 
> wrote:
> > > >
> > > > Congrats Caleb! Well deserved :)
> > > >
> > > > ~Charles
> > > >
> > > >> On May 14, 2021, at 07:30, Yifan Cai  wrote:
> > > >>
> > > >> Congrats Caleb!
> > > >>
> > > >>> On May 14, 2021, at 6:56 AM, Joshua McKenzie  >
> > > wrote:
> > > >>>
> > > >>> Congrats Caleb!
> > > >>>
> > > > On Fri, May 14, 2021 at 9:10 AM Brandon Williams <
> dri...@gmail.com
> > >
> > > wrote:
> > > 
> > >  Congrats Caleb! Well deserved.
> > > 
> > > > On Fri, May 14, 2021, 8:03 AM Mick Semb Wever 
> > > wrote:
> > > >
> > > > The PMC members are pleased to announce that Caleb Rackliffe has
> > > > accepted the invitation to become committer.
> > > >
> > > > Thanks heaps Caleb for helping make Cassandra awesome!
> > > >
> > > > Congratulations and welcome,
> > > > The Apache Cassandra PMC members
> > > >
> > > 
> > > >>
> > > >>
> -
> > > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >>
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >
>

Re: [VOTE] Release Apache Cassandra 4.0-rc2

[Andrés de la Peña]

+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 Mon, 28 Jun 2021 at 11:39, Aleksey Yeschenko 
> wrote:
> > >>
> > >> +1
> > >>
> >  On 28 Jun 2021, at 14:05, Gary Dusbabek 
> wrote:
> > >>>
> > >>> +1; yay!
> > >>>
> >  On Sun, Jun 27, 2021 at 11:02 AM Mick Semb Wever 
> wrote:
> > >>>
> >  Proposing the test build of Cassandra 4.0-rc2 for release.
> > 
> >  sha1: 4c98576533e1d7663baf447e8877788096489165
> >  Git:
> > 
> > 
> > >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc2-tentative
> >  Maven Artifacts:
> > 
> > 
> > >>
> https://repository.apache.org/content/repositories/orgapachecassandra-1237/org/apache/cassandra/cassandra-all/4.0-rc2/
> > 
> >  The Source and Build Artifacts, and the Debian and RPM packages and
> >  repositories, are available here:
> >  https://dist.apache.org/repos/dist/dev/cassandra/4.0-rc2/
> > 
> >  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]: CHANGES.txt:
> > 
> > 
> > >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-rc2-tentative
> >  [2]: NEWS.txt:
> > 
> > 
> > >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-rc2-tentative
> >  [3]: The maven artifacts were accidentally prematurely made public.
> Docs
> >  have been updated to prevent this happening again.
> > 
> > >>
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >>
> > >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Release Apache Cassandra 4.0.0

[Andrés de la Peña]

+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
>
>
> Tested:
> Hashes match.
> Signatures match.
> Source artefact builds. (and doesn't contain compiled dependencies)
> Tarball Binary artefact runs.
> Debian binary package runs.
> Redhat binary package runs.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Release Apache Cassandra 4.0.0 (take2)

[Andrés de la Peña]

+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: 924bf92fab1820942137138c779004acaf834187
> > > Git:
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.0-tentative
> > > Maven Artifacts:
> > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1242/org/apache/cassandra/cassandra-all/4.0.0/
> > >
> > > The Source and Build Artifacts, and the Debian and RPM packages and
> > > repositories, are available here:
> > > https://dist.apache.org/repos/dist/dev/cassandra/4.0.0/
> > >
> > > 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]: CHANGES.txt:
> > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.0-tentative
> > > [2]: NEWS.txt:
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.0-tentative
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >
>

Re: [VOTE] Release Apache Cassandra 4.0.0 (third time is the charm)

[Andrés de la Peña]

+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:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.0-tentative
> > Maven Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1244/org/apache/cassandra/cassandra-all/4.0.0/
> >
> > The Source and Build Artifacts, and Debian and RPM packages and
> > repositories are available here:
> > https://dist.apache.org/repos/dist/dev/cassandra/4.0.0/
> >
> > 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]: CHANGES.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.0-tentative
> > [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.0-tentative
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Release Apache Cassandra 3.0.25

[Andrés de la Peña]

+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: 06235e93e16d1f483a3b03ba02f8fb29e33305fa
> > > Git:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.25-tentative
> > > Maven Artifacts:
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1245/org/apache/cassandra/cassandra-all/3.0.25/
> > >
> > > The Source and Build Artifacts, and the Debian and RPM packages and
> > > repositories, are available here:
> > > https://dist.apache.org/repos/dist/dev/cassandra/3.0.25/
> > >
> > > 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]: CHANGES.txt:
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.25-tentative
> > > [2]: NEWS.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.25-tentative
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: [VOTE] Release Apache Cassandra 3.11.11

[Andrés de la Peña]

+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: 4cafe2288e56e1135d65e76adbcd6c2de9306d6b
> > > Git:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.11-tentative
> > > Maven Artifacts:
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1246/org/apache/cassandra/cassandra-all/3.11.11/
> > >
> > > The Source and Build Artifacts, and the Debian and RPM packages and
> > > repositories, are available here:
> > > https://dist.apache.org/repos/dist/dev/cassandra/3.11.11/
> > > 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]: CHANGES.txt:
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.11-tentative
> > > [2]: NEWS.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.11-tentative
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: Welcome Jon Meredith as Cassandra committer

[Andrés de la Peña]

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 11:20, Benjamin Lerer  >
> >> escreveu:
> >>
> >> Congratulations Jon. :-)
> >>
> >> Le ven. 30 juil. 2021 à 15:42, Ekaterina Dimitrova <
> e.dimitr...@gmail.com>
> >> a écrit :
> >>
> >>> Congrats!!! Well deserved!!! 🎉 👏🏻
> >>>
>  On Fri, 30 Jul 2021 at 9:32, Jonathan Ellis 
> wrote:
> >>>
>  Congratulations, Jon!
> 
>  On Fri, Jul 30, 2021 at 8:29 AM Brandon Williams 
> >>> wrote:
> 
> > The Project Management Committee (PMC) for Apache Cassandra
> > has invited Jon Meredith to become a committer and we are pleased
> > to announce that he has accepted.
> >
> > Thanks for all helping make Cassandra great!
> >
> > Congratulations,
> > The Apache Cassandra PMC members
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
> 
>  --
>  Jonathan Ellis
>  co-founder, http://www.datastax.com
>  @spyced
> 
> >>>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Save CircleCI resources with optional test jobs

[Andrés de la Peña]

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 running these test jobs. I'd say that frequently it
is not necessary to run the tests for some of those intermediate commits
and pushes. For example, one can show proofs of concept, or have multiple
rounds of review before actually running the tests. Running the tests for
every change can produce an unnecessary expense of CircleCI resources.

I think we could make running those tests optional, as well as clearly
specifying in the documentation what are the tests runs that are mandatory
before actually committing. We could do this in different ways:

1. Make the entire CircleCI workflow optional, so the build job requires
manual approval. Once the build is approved the mandatory test jobs would
be run without any further approval, exactly as it's currently done.

2. Make all the test jobs optional, so every test job requires manual
approval, and the documentation specifies which tests are mandatory in the
final steps of a ticket.

3. Make all the mandatory test jobs depend on a single optional job, so we
have a single button to optionally run all the mandatory tests.

I think any of these changes, or a combination of them, would significantly
reduce the usage of resources without making things less tested. The only
downside I can think of is that we would need some additional clicks on the
CircleCI GUI. What do you think?

Re: [DISCUSS] Jira state for second reviewer

[Andrés de la Peña]

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
> Committer Needed which made me think that this may be probably an even
> better option here based on the states meanings I outlined for myself:
>
> PATCH AVAILABLE - we have a patch; No reviewer has started working on
> review - neither committer, nor non-committer. We have a lonely
> non-committer patch waiting for committers’ attention.
> IN REVIEW - we already satisfy the 2 committers reviews requirement and
> they are both “in progress reviews”. NOTE: We rely on the committers to
> follow up with non-committers who might be also reviewing whether the patch
> can already be committed or not; after the two committers required have
> approved the patch.
> COMMITTER NEEDED:
> - 1st option - we need only one committer to join the review effort in
> order to satisfy the requirement of two committers’ approval in order to
> commit a patch.
> - 2nd option - we are waiting for a second committer’s review to start or
> even both committers’ reviews to start. It doesn't matter which reviewer
> was assigned first or second or who starts when, we don’t have the two
> needed committers’ reviews started yet.
>
> Does this make more sense?
> Do I miss any cases or misunderstood anything?
>
> On Mon, 2 Aug 2021 at 10:45, bened...@apache.org 
> wrote:
>
> > So, I don’t feel strongly about this at all, I just think it will be more
> > confusing this way so lead to more inconsistency of usage, as it will be
> > unclear what this second reviewer should do if they don’t start reviewing
> > immediately, so some tickets will remain in “Needs Second Reviewer” when
> it
> > doesn’t, and others will be in “In Review” when it isn’t.
> >
> > It will also be more burdensome to find out the true state of a ticket:
> if
> > the new reviewer transitions a ticket to “In Review” but doesn’t in fact
> > start review, you now need to ask a human being if they’re really
> reviewing
> > something or not, there’s no way to find out by yourself. If the
> “Awaiting
> > Second Review” state is interpreted as perhaps only needing a second
> > reviewer, a report can easily distinguish this by listing the contents of
> > the Reviewers column.
> >
> > But, I don’t anticipate losing any sleep over whatever we decide here.
> >
> > From: Ekaterina Dimitrova 
> > Date: Monday, 2 August 2021 at 15:37
> > To: dev@cassandra.apache.org 
> > Subject: Re: [DISCUSS] Jira state for second reviewer
> > My only worry is that If we incorporate both things in one state this
> means
> > that people won’t be able to find immediately tickets to assign for
> review.
> > They will have to go and check whether it needs a reviewer or just the
> > second reviewer haven’t started review yet. That is why I suggested then
> to
> > have both “Needs Second Reviewer” and “Awaiting Second Review” as indeed,
> > we can’t expect that people will immediately start a review when they
> > assign themselves as a reviewer. That I totally agree with. My only point
> > is that we need a state that incorporates really only one state - “we
> need
> > a person to help with review” and no other meaning. Otherwise triaging
> will
> > be again harder. IMHO this will help us to produce good reports and
> easily
> > identify spots that need attention/help.
> > I don’t disagree with you, I just think this is one additional point we
> > have to consider separately.
> >
> > On Mon, 2 Aug 2021 at 10:17, bened...@apache.org 
> > wrote:
> >
> > > I was proposing substituting “Needs Second Reviewer” for “Awaiting
> Second
> > > Review” as this encapsulates the need for an additional reviewer _and_
> > the
> > > pending status for the review beginning.
> > >
> > > I don’t think it is reasonable to assume that once a reviewer is found
> > > that they will move it into “In Review” nor would that be very helpful,
> > as
> > > we would not know which tickets were actively under review as opposed
> to
> > > pending review by an agreed second reviewer.
> > >
> > > From: Ekaterina Dimitrova 
> > > Date: Monday, 2 August 2021 at 15:15
> > > To: dev@cassandra.apache.org 
> > > Subject: Re: [DISCUSS] Jira state for second reviewer
> > > Thank you all.
> > > On Benedict’s question, my understanding is that the idea of Needs
> Second
> > > Reviewer is to indicate we need to find a second reviewer. I suspect
> when
> > > we find one he/she will move it to “In review” and provide status
> updates
> > > in the ticket. I am open for better suggestions.
> > > I guess “Awaiting Second Review” can be added to show that we have
> > > reviewers but the second review is not started yet? I would personally
> > > probably skip adding it and rely that people will follow up on their
> > > assignments. If we incorporate the alerts suggestions

Re: Welcome Adam Holmberg as Cassandra committer

[Andrés de la Peña]

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:
> >
> > >  The PMC members are pleased to announce that Adam Holmberg has
> accepted
> > > the invitation to become committer.
> > >
> > > Thanks a lot, Adam, for everything you have done for the project all
> > these
> > > years.
> > >
> > > Congratulations and welcome
> > >
> > > The Apache Cassandra PMC members
> > >
> >
> >
> > --
> > Jonathan Ellis
> > co-founder, http://www.datastax.com
> > @spyced
> >
>

Re: [VOTE] CEP-11: Pluggable memtable implementations

[Andrés de la Peña]

+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 memtable implementations
> > +1
> >
> > On Thu, Aug 19, 2021 at 11:11 AM Branimir Lambov 
> > wrote:
> > >
> > > Hello everyone,
> > >
> > > I am proposing the CEP-11 (Pluggable memtable implementations) for
> > adoption
> > >
> > > Discussion thread:
> > >
> >
> https://lists.apache.org/thread.html/rb5e950f882196764744c31bc3c13dfbf0603cb9f8bc2f6cfb976d285%40%3Cdev.cassandra.apache.org%3E
> > >
> > >
> > > The vote will be open for 72 hours.
> > > Votes by PMC members are considered binding.
> > > A vote passes if there are at least three binding +1s and no binding
> > vetoes.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>

Re: Save CircleCI resources with optional test jobs

[Andrés de la Peña]

Hi,

CASSANDRA-16882 has patches for any of the mentioned configurations aimed
to save CircleCI resources.

There are CircleCI runs showing how each approach would look like, plus an
additional fourth option:

1. Make the entire workflow optional:
https://app.circleci.com/pipelines/github/adelapena/cassandra/800/workflows/9cb8ca7b-ab57-431e-a22b-643d61c92c29
2. Make all the test jobs optional:
https://app.circleci.com/pipelines/github/adelapena/cassandra/798/workflows/a859cfbc-fdf8-4468-beb9-b2ee17dc1ae3
3. Make all the mandatory test jobs depend on a single optional job:
https://app.circleci.com/pipelines/github/adelapena/cassandra/802/workflows/0372f5d6-d1f0-4f0e-91a3-aa75a2712bae
4. Combine 2 and 3 to have approval jobs for both individual tests and the
grouped mandatory tests:
https://app.circleci.com/pipelines/github/adelapena/cassandra/803/workflows/08ae07d5-6a1e-4e5b-bc0c-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 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 running these test jobs. I'd say that frequently it
> is not necessary to run the tests for some of those intermediate commits
> and pushes. For example, one can show proofs of concept, or have multiple
> rounds of review before actually running the tests. Running the tests for
> every change can produce an unnecessary expense of CircleCI resources.
>
> I think we could make running those tests optional, as well as clearly
> specifying in the documentation what are the tests runs that are mandatory
> before actually committing. We could do this in different ways:
>
> 1. Make the entire CircleCI workflow optional, so the build job requires
> manual approval. Once the build is approved the mandatory test jobs would
> be run without any further approval, exactly as it's currently done.
>
> 2. Make all the test jobs optional, so every test job requires manual
> approval, and the documentation specifies which tests are mandatory in the
> final steps of a ticket.
>
> 3. Make all the mandatory test jobs depend on a single optional job, so we
> have a single button to optionally run all the mandatory tests.
>
> I think any of these changes, or a combination of them, would
> significantly reduce the usage of resources without making things less
> tested. The only downside I can think of is that we would need some
> additional clicks on the CircleCI GUI. What do you think?
>

Re: [VOTE] Release Apache Cassandra 4.0.1

[Andrés de la Peña]

+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 
> > > wrote:
> > > >
> > > > +1nb
> > > >
> > > >> On Sep 1, 2021, at 6:54 AM, Jeff Jirsa  wrote:
> > > >>
> > > >> +1
> > > >>
> > > >>
> > >  On Wed, Sep 1, 2021 at 4:54 AM Sam Tunnicliffe 
> > > wrote:
> > > >>>
> > > >>> Proposing the test build of Cassandra 4.0.1 for release.
> > > >>>
> > > >>> sha1: 6709111ed007a54b3e42884853f89cabd38e4316
> > > >>> Git:
> > > >>>
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.1-tentative
> > > >>> Maven Artifacts:
> > > >>>
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1247/org/apache/cassandra/cassandra-all/4.0.1/
> > > >>>
> > > >>> The Source and Build Artifacts, and the Debian and RPM packages and
> > > >>> repositories, are available here:
> > > >>> https://dist.apache.org/repos/dist/dev/cassandra/4.0.1/
> > > >>>
> > > >>> 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]: CHANGES.txt:
> > > >>>
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.1-tentative
> > > >>> [2]: NEWS.txt:
> > > >>>
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.1-tentative
> > > >>>
> > > >>>
> > > >>>
> -
> > > >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > >>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >>>
> > > >>>
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >
>

New resource flags in CircleCI config generation script

[Andrés de la Peña]

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 useful when editing the CircleCI config env vars, for example
to set the dtest repo or to use the test multiplexer. This process usually
involves swapping the config.yml file to get the proper resources and then
to manually edit the multiple mentions of DTEST_REPO, DTEST_BRANCH, etc. in
the swapped file. With the new flags one can instead just edit the single
mention of the vars in the config-2_1.yml file and then run the generation
script to validate the config and generate the modified config.yml with the
desired resources configuration.

The new flags have been introduced by CASSANDRA-16871 and they are
mentioned in the readme for CircleCI:
https://github.com/apache/cassandra/blob/trunk/.circleci/readme.md

Re: Keeping on top of test failures

[Andrés de la Peña]

+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 building up and getting burned down, but don't really have a
> > workflow or discipline around having a clean snapshot of where we are or
> > attempting to stay at some kind of steady state. We have thousands of
> tests
> > executing in a wide variety of environments: this state is to be
> expected,
> > but I argue needs to be actively managed so we don't get into the kind of
> > situation we did with 4.0 again.
> >
> > I threw together a couple of JIRA queries that paint a pretty navigable
> > picture IMO:
> >
> > Total JIRA for test failures:
> >
> https://issues.apache.org/jira/issues/?filter=12350869&jql=project%20%3D%20Cassandra%20AND%20resolution%20%3D%20unresolved%20AND%20(summary%20~%20flaky%20OR%20summary%20~%20test%20OR%20component%20%3D%20%22Test%2Funit%22)%20AND%20type%20%3D%20bug%20AND%20issuekey%20not%20in%20(CASSANDRA-16010%2C%20CASSANDRA-16024%2C%20CASSANDRA-16022%2C%20CASSANDRA-16021%2C%20CASSANDRA-16025%2C%20CASSANDRA-16023)%20AND%20summary%20!~%20hardening%20ORDER%20BY%20cf%5B12313825%5D%20ASC
> > (sorry for the URL) - 112 failures
> >
> > # of failures more recent than 6 months:
> > https://issues.apache.org/jira/issues/?filter=12350869
> > 10 failures.
> >
> > In the interest of tidying this up and staying on top of it going
> forward,
> > I propose the following:
> > 1. We close as won't fix all test failures created >= 6 months ago (We
> had
> > a big push for 4.0 and a lot of this JIRA content is stale)
> > 2. We switch the "Bug Category" for these 10 more recent to "Correctness
> -
> > Test Failure"
> > 3. We document a "canonical" workflow around test failures that links to
> a
> > saved JIRA filter query that includes:
> > 4. When you're working on something and you see a test failure that isn't
> > related to your patch, check that filter, see if the test name is there,
> > and if not create a new ticket w/that Bug Category
> >
> > In theory this should give us a single source of truth for documented
> test
> > failures as well as an entry point for new contributors.
> >
> > Thoughts?
> >
> > ~Josh
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Welcome Aleksei Zotov as Cassandra committer

[Andrés de la Peña]

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 your contributions to the project over the
> > years.
> >
> > Congratulations and welcome
> >
> > The Apache Cassandra PMC members
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: New resource flags in CircleCI config generation script

[Andrés de la Peña]

Following this up, CASSANDRA-16989 allows to pass CircleCI env vars to the
config generation script. For example, to set mid resources and the dtest
branch and repo one can run:

.circleci/generate.sh -m \
  -e DTEST_REPO=git://github.com/adelapena/cassandra-dtest.git \
  -e DTEST_BRANCH=CASSANDRA-8272

As another example, to set the test multiplexer with highres:

generate.sh -h \
  -e REPEATED_UTEST_TARGET=testsome \
  -e REPEATED_UTEST_CLASS=org.apache.cassandra.cql3.ViewTest \
  -e REPEATED_UTEST_METHODS=testCompoundPartitionKey,testStaticTable \
  -e REPEATED_UTEST_COUNT=100

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/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 useful when editing the CircleCI config env vars, for
> example to set the dtest repo or to use the test multiplexer. This process
> usually involves swapping the config.yml file to get the proper resources
> and then to manually edit the multiple mentions
> of DTEST_REPO, DTEST_BRANCH, etc. in the swapped file. With the new flags
> one can instead just edit the single mention of the vars in the
> config-2_1.yml file and then run the generation script to validate the
> config and generate the modified config.yml with the desired resources
> configuration.
>
> The new flags have been introduced by CASSANDRA-16871 and they are
> mentioned in the readme for CircleCI:
> https://github.com/apache/cassandra/blob/trunk/.circleci/readme.md
>
>
>

Re: Save CircleCI resources with optional test jobs

[Andrés de la Peña]

Hello all,

The changes in CircleCI proposed in the previous messages are implemented
in CASSANDRA-16882. They try to include the feedback from both the
reviewers and the Slack discussion at
https://the-asf.slack.com/archives/CK23JSY2K/p1631627458109000.

The patch modifies the CircleCI config to have two pairs of j8/j11
workflows:

* The javaX_pre-commit_tests workflows are meant to be used when a patch is
definitively ready for final review and/or commit. They have a single
approval step that starts all the basic tests, including unit tests,
dtests, etc. Additionally, it has approval steps for those tests that are
not generally required in every ticket, such as upgrade tests and the
multiplexer. This pair of workflows is quite similar to what we currently
have, and the main difference is that there is an approval step to start
the build.

* The javaX_separate_tests workflows are meant to be used in intermediate
steps and special cases such as fixing flaky tests. All the jobs in these
workflows have an individual approval step, so one can run any test job
without wasting resources in the others. For example, it makes possible to
repeatedly run a unit test without firing the entire JVM dtests.

Here is an example of how the workflows would look like:
https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=16882-option-7-trunk-v04

Hopefully this approach would help us to save resources in intermediate
development steps and special cases, while keeping 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 CircleCI resources.
>
> There are CircleCI runs showing how each approach would look like, plus an
> additional fourth option:
>
> 1. Make the entire workflow optional:
> https://app.circleci.com/pipelines/github/adelapena/cassandra/800/workflows/9cb8ca7b-ab57-431e-a22b-643d61c92c29
> 2. Make all the test jobs optional:
> https://app.circleci.com/pipelines/github/adelapena/cassandra/798/workflows/a859cfbc-fdf8-4468-beb9-b2ee17dc1ae3
> 3. Make all the mandatory test jobs depend on a single optional job:
> https://app.circleci.com/pipelines/github/adelapena/cassandra/802/workflows/0372f5d6-d1f0-4f0e-91a3-aa75a2712bae
> 4. Combine 2 and 3 to have approval jobs for both individual tests and the
> grouped mandatory tests:
> https://app.circleci.com/pipelines/github/adelapena/cassandra/803/workflows/08ae07d5-6a1e-4e5b-bc0c-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 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 running these test jobs. I'd say that frequently it
>> is not necessary to run the tests for some of those intermediate commits
>> and pushes. For example, one can show proofs of concept, or have multiple
>> rounds of review before actually running the tests. Running the tests for
>> every change can produce an unnecessary expense of CircleCI resources.
>>
>> I think we could make running those tests optional, as well as clearly
>> specifying in the documentation what are the tests runs that are mandatory
>> before actually committing. We could do this in different ways:
>>
>> 1. Make the entire CircleCI workflow optional, so the build job requires
>> manual approval. Once the build is approved the mandatory test jobs would
>> be run without any further approval, exactly as it's currently done.
>>
>> 2. Make all the test jobs optional, so every test job requires manual
>> approval, and the documentation specifies which tests are mandatory in the
>> final steps of a ticket.
>>
>> 3. Make all the mandatory test jobs depend on a single optional job, so
>> we have a single button to optionally run all the mandatory tests.
>>
>> I think any of these changes, or a combination of them, would
>> significantly reduce the usage of resources without making things less
>> tested. The only downside I can think of is that we would need some
>> additional clicks on the CircleCI GUI. What do you think?
>>
>

Re: Save CircleCI resources with optional test jobs

[Andrés de la Peña]

fore a commit. Links
> with
> > the different versions/suggestions of the workflow are published on the
> > ticket.
> >
> > Yes, now we need to click on the build. It was agreed that many times
> > people push even just to preserve intermediate work and continue later
> > without caring of build or anything. If for some reason it is important
> to
> > you or anyone else from the community to build on every commit, we can
> open
> > a ticket to change that. It will save a click or two in the case of the
> > in-jvm upgrade tests. I would like to point out that Andres was also
> > experimenting to ensure that the graph will be still as much readable as
> > possible.
> >
> > Benedict, on your comment of feature request - we can do that. I am also
> > sceptic as you if that will happen but this doesn’t mean we can’t give
> it a
> > try. Who knows, maybe others are also raising the topic and they might
> > consider it.
> >
> > Honestly, I personally support the current workflow and approval required
> > but if it is not acceptable to others and skipping the build approval
> click
> > is what others would prefer, I will open a ticket to restore that part.
> > Please let me know and one more time, apologize for missing your email,
> > Alex.
> >
> > Best regards,
> > Ekaterina
> >
> >
> >
> > On Wed, 20 Oct 2021 at 9:01, bened...@apache.org 
> > wrote:
> >
> > > I think this would be fine if there were a way for approval of later
> steps
> > > to trigger the build automatically. As it is we have to traverse the
> > > dependency graph manually, which is a bit weird.
> > >
> > > I can’t figure out a way to do this with the CircleCI API however. It
> > > might be a feature request, and perhaps we can at least trigger the
> build
> > > until we get that (which may never happen).
> > >
> > > From: Oleksandr Petrov 
> > > Date: Wednesday, 20 October 2021 at 13:35
> > > To: dev 
> > > 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 done on
> > > every commit now?
> > >
> > >
> > > On Fri, Oct 8, 2021 at 4:12 PM Oleksandr Petrov <
> > > oleksandr.pet...@gmail.com>
> > > wrote:
> > >
> > > > I personally rarely push tickets/post a patch in an raw state, but
> since
> > > I
> > > > almost always have to approve jobs when it gets close to commit, I
> don't
> > > > mind also confirming utest runs. I'd say it'd be good to run at very
> > > least
> > > > a compilation step on every commit. I think it's fine if
> > > dtests/utests/jvm
> > > > tests require approval.
> > > >
> > > > On Wed, Oct 6, 2021 at 4:22 PM Andrés de la Peña <
> adelap...@apache.org>
> > > > wrote:
> > > >
> > > >> Hello all,
> > > >>
> > > >> The changes in CircleCI proposed in the previous messages are
> > > implemented
> > > >> in CASSANDRA-16882. They try to include the feedback from both the
> > > >> reviewers and the Slack discussion at
> > > >> https://the-asf.slack.com/archives/CK23JSY2K/p1631627458109000.
> > > >>
> > > >> The patch modifies the CircleCI config to have two pairs of j8/j11
> > > >> workflows:
> > > >>
> > > >> * The javaX_pre-commit_tests workflows are meant to be used when a
> patch
> > > >> is
> > > >> definitively ready for final review and/or commit. They have a
> single
> > > >> approval step that starts all the basic tests, including unit tests,
> > > >> dtests, etc. Additionally, it has approval steps for those tests
> that
> > > are
> > > >> not generally required in every ticket, such as upgrade tests and
> the
> > > >> multiplexer. This pair of workflows is quite similar to what we
> > > currently
> > > >> have, and the main difference is that there is an approval step to
> start
> > > >> the build.
> > > >>
> > > >> * The javaX_separate_tests workflows are meant to be used in
> > > intermediate
> > > >> steps and special cases such as fixing flaky tests. All the jobs in

Re: Save CircleCI resources with optional test jobs

[Andrés de la Peña]

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 cases. The j8/j11 pre-commit workflows are for
final stages, and it’s probably what those who push mostly-final patches
would use. I think that these folks can just ignore the separate-tests
workflows and use the “run everything” approval step on the pre-commit
workflow.

Focusing on those who push mostly final patches, and therefore use the
pre-commit workflow, would there any value on running the build
automatically and then requesting manual approval to run all the tests? If
the patch is almost ready the tests have to be run, so I think there isn’t
a difference between running the build step or not. In the end, we still
have to press a single approval step, and if the build fails the tests
aren’t going to start.


El El jue, 21 oct 2021 a las 14:47, Oleksandr Petrov <
oleksandr.pet...@gmail.com> escribió:

> Thank you for responding,
>
> If there's an option that Benedict has suggested (to allow folks who push
> mostly-final patches, and the folks who push rather-early patches and 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,
> >
> > As Ekaterina has mentioned I’ll be OOO until Monday, and I won’t be able
> to
> > make any changes until then.
> >
> > Alex, I missed to answer your suggestion about building on every commit,
> > apologies for that. The discussion was open on multiple fronts and I
> > somehow missed that one. I can easily change it back to automatic builds
> on
> > Monday if we prefer to do so.
> >
> > The pre-commit workflows have a single button to start the build and all
> > the tests that were previously run automatically. If we had automatic
> > builds we would still have a button to start the tests. Thus, I think
> that
> > automatic builds in the pre-commit workflow would’t make a difference in
> > terms of usability, and we would be wasting resources in intermediate
> > commits.
> >
> > As for the workflows with separate approval steps, the automatic build
> > would save us a click at the cost of wasting resources in some cases.
> Since
> > the cost of building is not that high it might make more sense to have
> > automatic builds in these workflows. Alternatively, a detail that could
> > improve things a bit in the separate-tests workflows is making the
> approval
> > steps for running the tests depend on the approval for the build. That
> > wouldn’t save us any clicks but it would make impossible to miss the
> build
> > approval, since we would need to click it in order to enable the buttons
> > starting the tests.
> >
> > It would be really great if the build started when one approves a certain
> > test job, but as it has been mentioned that doesn’t seem possible with
> the
> > current CircleCI features.
> >
> > Having a config that entirely satisfies the needs of everyone doesn’t
> seem
> > possible, and I also think that we’ll eventually need better tooling to
> > generate the config file, although we still need to agree on a default
> > config. CASSANDRA-16989 has recently added flags to the config generation
> > script allowing to swap resources and specify the environment vars. We
> > should probably continue adding similar options to be able to manipulate
> > the approval steps, parallelism, etc.
> >
> > Regards,
> >
> > El El mié, 20 oct 2021 a las 18:03, bened...@apache.org <
> > bened...@apache.org>
> > escribió:
> >
> > > Perhaps instead of a one-size-fits-all policy we should look to improve
> > > scripting here anyway. We already have to overwrite the config file, it
> > > would seem easy enough to instead invoke a script that enables the
> > relevant
> > > workflows?
> > >
> > > If we choose to just stick with a single workflow, I don’t have a super
> > > strong preference for one approach or the other.
> > >
> > > From: Stefan Miklosovic 
> > > Date: Wednesday, 20 October 2021 at 16:58
> > > To: dev@cassandra.apache.org 
> > > Subject: Re: Save CircleCI resources with optional test jobs
> > > Hi Ekaterina, all,
> > >
> > > If you eventually decide to switch it to automatic build on push (I
> > > like how it is now though), I would appreciate it if there was some
> > > option in

Re: Save CircleCI resources with optional test jobs

[Andrés de la Peña]

Hi all,

I have just created CASSANDRA-17113 adding scripting options to select the
workflow to be used, trying to implement Benedict's suggestion.

It adds some flags to the existing .circleci/generate.sh config generation
script. A -p flag generates only the pre-commit workflows, whereas a -s
flag generates only the workflows with separate approval steps for each
test job. Both flags can be used together to generate the two pairs of
workflows. The default option is generating all the workflows, so users can
decide what workflow are they going to use in the CircleCI GUI, after
pushing their changes. We can easily change the workflows that are
generated by default to anything that suits us better.

Additionally, there is a -r flag that disables the first approval step of
the generated workflows. For the separate_tests workflows it means that the
build is automatically run, but the individual steps still need to be
manually approved in the GUI. For the pre-commit_tests workflows, the -r
flag will automatically run the build and the most relevant tests. That
way, users pushing a mostly ready patch and wanting to run the tests with
HIGHRES would probably want to generate 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 cases. The j8/j11 pre-commit workflows are for
> final stages, and it’s probably what those who push mostly-final patches
> would use. I think that these folks can just ignore the separate-tests
> workflows and use the “run everything” approval step on the pre-commit
> workflow.
>
> Focusing on those who push mostly final patches, and therefore use the
> pre-commit workflow, would there any value on running the build
> automatically and then requesting manual approval to run all the tests? If
> the patch is almost ready the tests have to be run, so I think there isn’t
> a difference between running the build step or not. In the end, we still
> have to press a single approval step, and if the build fails the tests
> aren’t going to start.
>
>
> El El jue, 21 oct 2021 a las 14:47, Oleksandr Petrov <
> oleksandr.pet...@gmail.com> escribió:
>
>> Thank you for responding,
>>
>> If there's an option that Benedict has suggested (to allow folks who push
>> mostly-final patches, and the folks who push rather-early patches and 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,
>> >
>> > As Ekaterina has mentioned I’ll be OOO until Monday, and I won’t be
>> able to
>> > make any changes until then.
>> >
>> > Alex, I missed to answer your suggestion about building on every commit,
>> > apologies for that. The discussion was open on multiple fronts and I
>> > somehow missed that one. I can easily change it back to automatic
>> builds on
>> > Monday if we prefer to do so.
>> >
>> > The pre-commit workflows have a single button to start the build and all
>> > the tests that were previously run automatically. If we had automatic
>> > builds we would still have a button to start the tests. Thus, I think
>> that
>> > automatic builds in the pre-commit workflow would’t make a difference in
>> > terms of usability, and we would be wasting resources in intermediate
>> > commits.
>> >
>> > As for the workflows with separate approval steps, the automatic build
>> > would save us a click at the cost of wasting resources in some cases.
>> Since
>> > the cost of building is not that high it might make more sense to have
>> > automatic builds in these workflows. Alternatively, a detail that could
>> > improve things a bit in the separate-tests workflows is making the
>> approval
>> > steps for running the tests depend on the approval for the build. That
>> > wouldn’t save us any clicks but it would make impossible to miss the
>> build
>> > approval, since we would need to click it in order to enable the buttons
>> > starting the tests.
>> >
>> > It would be really great if the build started when one approves a
>> certain
>> > test job, but as it has been mentioned that doesn’t seem possible with
>> the
>> > current CircleCI features.
>> >
>> > Having a config that entirely satisfies the 

[DISCUSS] CEP-3: Guardrails

[Andrés de la Peña]

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 not possible
to severely degrade the performance of a node/cluster through user actions
such as having too many secondary indexes, too large partitions, almost
full disks, etc.

Thanks,

Re: [DISCUSS] CEP-3: Guardrails

[Andrés de la Peña]

Being able to configure guardrails dynamically makes a lot of sense to me,
I have updated the CEP to mention that. I think we don't need to decide yet
whether it would be done through JMX and/or virtual tables.

On Mon, 1 Nov 2021 at 20:35, C. Scott Andreas  wrote:

> Re: "I think you all know my feels on JMX." –
>
> Super fair - I'd meant to speak in terms of desired outcome ("the feature
> should be dynamically configurable at runtime") rather than implementation
> ("this should be via JMX"). 👍
>
> On Nov 1, 2021, at 1:24 PM, David Capwell 
> wrote:
>
>
> If anyone wants to bite off making
> https://github.com/apache/cassandra/blob/ab920c30310a8c095ba76b363142b8e74cbf0a0a/src/java/org/apache/cassandra/db/virtual/SettingsTable.java
> <
> https://github.com/apache/cassandra/blob/ab920c30310a8c095ba76b363142b8e74cbf0a0a/src/java/org/apache/cassandra/db/virtual/SettingsTable.java>
> support mutability then we get vtable support. I am cool with JMX and/or
> vtable, to me its just more important to allow dynamic setting of these
> configs.
>
> On Nov 1, 2021, at 10:36 AM, bened...@apache.org wrote:
>
> having them only configured via yaml seems like a bad outcome
>
>
> +1
>
> I would like to see us move towards configuration being driven through
> virtual tables where possible, so that the whole cluster can be managed
> from a single interface. Not sure if this is the right place to bite this
> off, but perhaps?
>
> From: Jeff Jirsa 
> Date: Monday, 1 November 2021 at 16:47
> To: Cassandra DEV 
> Subject: Re: [DISCUSS] CEP-3: Guardrails
> Without bike-shedding too much, guardrails would be great, building them
> into a more general purpose framework that limits various dangerous things
> would be fantastic. The CEP says that the guardrails should be distinct
> from the capability restrictions (
> https://issues.apache.org/jira/browse/CASSANDRA-8303 ), but I don't see
> why
> that needs to be the case. A system-level guardrail and a personal-level
> guardrail are both restrictions, they just have different scopes, so
> implement the restriction framework first, and allow the scopes to be
> expanded as needed?
>
> Naming wise, I don't know that I'd actually surface these as "guardrails",
> 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 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 not possible
> to severely degrade the performance of a node/cluster through user actions
> such as having too many secondary indexes, too large partitions, almost
> full disks, etc.
>
> Thanks,
>
>
>
>
>
>

Re: [DISCUSS] CEP-3: Guardrails

[Andrés de la Peña]

>
> Under "Migrating existing cassandra.yaml warn/fail thresholds”, I recently
> added a few things which are basically guardrails, so should be included in
> this set; they are configured by track_warnings (coordinator_read_size,
> local_read_size, and row_index_size).  With track_warnings I setup the
> plumbing to have read queries trigger warnings (or abort the query) to the
> client exists (under "Event logging" you mention "and also to the client
> connection when applicable”) and isn’t limited to the coordinator
> participating in the query (previous limitation for tombstone warnings).
> One thing I found which was problematic for track_warnings was that
> altering clients is annoying as java and python both ignore the error
> message we send (see
> https://github.com/datastax/java-driver/blob/3.11.0/driver-core/src/main/java/com/datastax/driver/core/Responses.java#L73-L131).
> We log client warnings (if enabled) but ignore any detailed error message
> received from the server; it would be good to talk about client
> integrations and how users are informed of issues in more detail.


I have updated the CEP to include those thresholds among the ones that
could be migrated once we have the guardrails framework ready. I have also
mentioned the usage of internal messaging to be able to propagate the
outcome of guardrails triggered on nodes that are not the coordinator, and
the need of making changes 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 la Peña 
wrote:

> Being able to configure guardrails dynamically makes a lot of sense to me,
> I have updated the CEP to mention that. I think we don't need to decide yet
> whether it would be done through JMX and/or virtual tables.
>
> On Mon, 1 Nov 2021 at 20:35, C. Scott Andreas 
> wrote:
>
>> Re: "I think you all know my feels on JMX." –
>>
>> Super fair - I'd meant to speak in terms of desired outcome ("the feature
>> should be dynamically configurable at runtime") rather than implementation
>> ("this should be via JMX"). 👍
>>
>> On Nov 1, 2021, at 1:24 PM, David Capwell 
>> wrote:
>>
>>
>> If anyone wants to bite off making
>> https://github.com/apache/cassandra/blob/ab920c30310a8c095ba76b363142b8e74cbf0a0a/src/java/org/apache/cassandra/db/virtual/SettingsTable.java
>> <
>> https://github.com/apache/cassandra/blob/ab920c30310a8c095ba76b363142b8e74cbf0a0a/src/java/org/apache/cassandra/db/virtual/SettingsTable.java>
>> support mutability then we get vtable support. I am cool with JMX and/or
>> vtable, to me its just more important to allow dynamic setting of these
>> configs.
>>
>> On Nov 1, 2021, at 10:36 AM, bened...@apache.org wrote:
>>
>> having them only configured via yaml seems like a bad outcome
>>
>>
>> +1
>>
>> I would like to see us move towards configuration being driven through
>> virtual tables where possible, so that the whole cluster can be managed
>> from a single interface. Not sure if this is the right place to bite this
>> off, but perhaps?
>>
>> From: Jeff Jirsa 
>> Date: Monday, 1 November 2021 at 16:47
>> To: Cassandra DEV 
>> Subject: Re: [DISCUSS] CEP-3: Guardrails
>> Without bike-shedding too much, guardrails would be great, building them
>> into a more general purpose framework that limits various dangerous things
>> would be fantastic. The CEP says that the guardrails should be distinct
>> from the capability restrictions (
>> https://issues.apache.org/jira/browse/CASSANDRA-8303 ), but I don't see
>> why
>> that needs to be the case. A system-level guardrail and a personal-level
>> guardrail are both restrictions, they just have different scopes, so
>> implement the restriction framework first, and allow the scopes to be
>> expanded as needed?
>>
>> Naming wise, I don't know that I'd actually surface these as "guardrails",
>> 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 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 not
>> possible
>> to severely degrade the performance of a node/cluster through user actions
>> such as having too many secondary indexes, too large partitions, almost
>> full disks, etc.
>>
>> Thanks,
>>
>>
>>
>>
>>
>>

Re: [DISCUSS] Releasable trunk and quality

[Andrés de la Peña]

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 add a new test or modify an existing one. Running those
jobs, when applicable, could be a requirement before committing. This
wouldn't help us when the changes affect many different tests or we are not
able to identify the tests affected by our changes, but I think it could
have prevented many of the recently fixed flakies.


On Thu, 4 Nov 2021 at 12:24, Joshua McKenzie  wrote:

> >
> > we noticed CI going from a
> > steady 3-ish failures to many and it's getting fixed. So we're moving in
> > the right direction imo.
> >
> An observation about this: there's tooling and technology widely in use to
> help prevent ever getting into this state (to Benedict's point: blocking
> merge on CI failure, or nightly tests and reverting regression commits,
> etc). I think there's significant time and energy savings for us in using
> automation to be proactive about the quality of our test boards rather than
> reactive.
>
> I 100% agree that it's heartening to see that the quality of the codebase
> is improving as is the discipline / attentiveness of our collective
> culture. That said, I believe we still have a pretty fragile system when it
> comes to test failure accumulation.
>
> On Thu, Nov 4, 2021 at 2:46 AM Berenguer Blasi 
> wrote:
>
> > I agree with David. CI has been pretty reliable besides the random
> > jenkins going down or timeout. The same 3 or 4 tests were the only flaky
> > ones in jenkins and Circle was very green. I bisected a couple failures
> > to legit code errors, David is fixing some more, others have as well, etc
> >
> > It is good news imo as we're just getting to learn our CI post 4.0 is
> > reliable and we need to start treating it as so and paying attention to
> > it's reports. Not perfect but reliable enough it would have prevented
> > those bugs getting merged.
> >
> > In fact we're having this conversation bc we noticed CI going from a
> > steady 3-ish failures to many and it's getting fixed. So we're moving in
> > the right direction imo.
> >
> > On 3/11/21 19:25, David Capwell wrote:
> > >> It’s hard to gate commit on a clean CI run when there’s flaky tests
> > > I agree, this is also why so much effort was done in 4.0 release to
> > remove as much as possible.  Just over 1 month ago we were not really
> > having a flaky test issue (outside of the sporadic timeout issues; my
> > circle ci runs were green constantly), and now the “flaky tests” I see
> are
> > all actual bugs (been root causing 2 out of the 3 I reported) and some
> (not
> > all) of the flakyness was triggered by recent changes in the past month.
> > >
> > > Right now people do not believe the failing test is caused by their
> > patch and attribute to flakiness, which then causes the builds to start
> > being flaky, which then leads to a different author coming to fix the
> > issue; this behavior is what I would love to see go away.  If we find a
> > flaky test, we should do the following
> > >
> > > 1) has it already been reported and who is working to fix?  Can we
> block
> > this patch on the test being fixed?  Flaky tests due to timing issues
> > normally are resolved very quickly, real bugs take longer.
> > > 2) if not reported, why?  If you are the first to see this issue than
> > good chance the patch caused the issue so should root cause.  If you are
> > not the first to see it, why did others not report it (we tend to be good
> > about this, even to the point Brandon has to mark the new tickets as
> dups…)?
> > >
> > > I have committed when there were flakiness, and I have caused
> flakiness;
> > not saying I am perfect or that I do the above, just saying that if we
> all
> > moved to the above model we could start relying on CI.  The biggest
> impact
> > to our stability is people actually root causing flaky tests.
> > >
> > >>  I think we're going to need a system that
> > >> understands the difference between success, failure, and timeouts
> > >
> > > I am curious how this system can know that the timeout is not an actual
> > failure.  There was a bug in 4.0 with time serialization in message,
> which
> > would cause the message to get dropped; this presented itself as a
> timeout
> > if I remember properly (Jon Meredith or Yifan Cai fixed this bug I
> believe).
> > >
> > >> On Nov 3, 2021, at 10:56 AM, Brandon Williams 
> wrote:
> > >>
> > >> On Wed, Nov 3, 2021 at 12:35 PM bened...@apache.org <
> > bened...@apache.org> wrote:
> > >>> The largest number of test failures turn out (as pointed out by
> David)
> > to be due to how arcane it was to trigger the full test suite. Hopefully
> we
> > can get on top of that, but I think a significant remaining issue is a
> lack
> > of trust in the output of CI. It’s hard to gate com

Re: [DISCUSS] CEP-3: Guardrails

[Andrés de la Peña]

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 are basically guardrails, so should be included in
>> this set; they are configured by track_warnings (coordinator_read_size,
>> local_read_size, and row_index_size).  With track_warnings I setup the
>> plumbing to have read queries trigger warnings (or abort the query) to the
>> client exists (under "Event logging" you mention "and also to the client
>> connection when applicable”) and isn’t limited to the coordinator
>> participating in the query (previous limitation for tombstone warnings).
>> One thing I found which was problematic for track_warnings was that
>> altering clients is annoying as java and python both ignore the error
>> message we send (see
>> https://github.com/datastax/java-driver/blob/3.11.0/driver-core/src/main/java/com/datastax/driver/core/Responses.java#L73-L131).
>> We log client warnings (if enabled) but ignore any detailed error message
>> received from the server; it would be good to talk about client
>> integrations and how users are informed of issues in more detail.
>
>
> I have updated the CEP to include those thresholds among the ones that
> could be migrated once we have the guardrails framework ready. I have also
> mentioned the usage of internal messaging to be able to propagate the
> outcome of guardrails triggered on nodes that are not the coordinator, and
> the need of making changes 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 la Peña 
> wrote:
>
>> Being able to configure guardrails dynamically makes a lot of sense to
>> me, I have updated the CEP to mention that. I think we don't need to decide
>> yet whether it would be done through JMX and/or virtual tables.
>>
>> On Mon, 1 Nov 2021 at 20:35, C. Scott Andreas 
>> wrote:
>>
>>> Re: "I think you all know my feels on JMX." –
>>>
>>> Super fair - I'd meant to speak in terms of desired outcome ("the
>>> feature should be dynamically configurable at runtime") rather than
>>> implementation ("this should be via JMX"). 👍
>>>
>>> On Nov 1, 2021, at 1:24 PM, David Capwell 
>>> wrote:
>>>
>>>
>>> If anyone wants to bite off making
>>> https://github.com/apache/cassandra/blob/ab920c30310a8c095ba76b363142b8e74cbf0a0a/src/java/org/apache/cassandra/db/virtual/SettingsTable.java
>>> <
>>> https://github.com/apache/cassandra/blob/ab920c30310a8c095ba76b363142b8e74cbf0a0a/src/java/org/apache/cassandra/db/virtual/SettingsTable.java>
>>> support mutability then we get vtable support. I am cool with JMX and/or
>>> vtable, to me its just more important to allow dynamic setting of these
>>> configs.
>>>
>>> On Nov 1, 2021, at 10:36 AM, bened...@apache.org wrote:
>>>
>>> having them only configured via yaml seems like a bad outcome
>>>
>>>
>>> +1
>>>
>>> I would like to see us move towards configuration being driven through
>>> virtual tables where possible, so that the whole cluster can be managed
>>> from a single interface. Not sure if this is the right place to bite this
>>> off, but perhaps?
>>>
>>> From: Jeff Jirsa 
>>> Date: Monday, 1 November 2021 at 16:47
>>> To: Cassandra DEV 
>>> Subject: Re: [DISCUSS] CEP-3: Guardrails
>>> Without bike-shedding too much, guardrails would be great, building them
>>> into a more general purpose framework that limits various dangerous
>>> things
>>> would be fantastic. The CEP says that the guardrails should be distinct
>>> from the capability restrictions (
>>> https://issues.apache.org/jira/browse/CASSANDRA-8303 ), but I don't see
>>> why
>>> that needs to be the case. A system-level guardrail and a personal-level
>>> guardrail are both restrictions, they just have different scopes, so
>>> implement the restriction framework first, and allow the scopes to be
>>> expanded as needed?
>>>
>>> Naming wise, I don't know that I'd actually surface these as
>>> "guar

Re: [DISCUSS] CEP-3: Guardrails

[Andrés de la Peña]

>
> I would love to see added something like “all guard rails must work in a
> rolling fashion where some nodes do not have the latest guard rails”, but
> also cool leaving this to JIRA.


Good point, I have added a line about the rolling behaviour.

The cassandra.yaml file is pretty big already and configuration of
> guardrails seems like a good candidate to modularize here. Could also be
> done during implementation (or discussed then), so don't hold up voting on
> me. :)


The configuration is supposed to go under a specific section in
cassandra.yaml. There was a colon character missed in the example, I have
fixed it to reflect that all guardrail parameters are grouped in a single
section. Nevertheless, we can always further discuss the details on how we
organize the config during implementation.


On Wed, 10 Nov 2021 at 20:16, Joshua McKenzie  wrote:

> Kind of a nit, but I advocate for us having a guardrails.yaml and updating
> this line:
>>
>> *cassandra.yaml:* allows configuring individual guardrails at startup,
>> being globally disabled by default. These guardrails will also be
>> dynamically configurable through JMX and/or virtual tables.
>
> The cassandra.yaml file is pretty big already and configuration of
> guardrails seems like a good candidate to modularize here. Could also be
> done during implementation (or discussed then), so don't hold up voting on
> me. :)
>
> On Wed, Nov 10, 2021 at 3:06 PM David Capwell 
> wrote:
>
>> I am cool with voting. I would love to see added something like “all
>> guard rails must work in a rolling fashion where some nodes do not have the
>> latest guard rails”, but also cool leaving this to JIRA.
>>
>> > On Nov 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:
>> >
>> >> 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 are basically guardrails, so should be
>> >> included in
>> >>>> this set; they are configured by track_warnings
>> (coordinator_read_size,
>> >>>> local_read_size, and row_index_size).  With track_warnings I setup
>> the
>> >>>> plumbing to have read queries trigger warnings (or abort the query)
>> to
>> >> the
>> >>>> client exists (under "Event logging" you mention "and also to the
>> client
>> >>>> connection when applicable”) and isn’t limited to the coordinator
>> >>>> participating in the query (previous limitation for tombstone
>> warnings).
>> >>>> One thing I found which was problematic for track_warnings was that
>> >>>> altering clients is annoying as java and python both ignore the error
>> >>>> message we send (see
>> >>>>
>> >>
>> https://github.com/datastax/java-driver/blob/3.11.0/driver-core/src/main/java/com/datastax/driver/core/Responses.java#L73-L131
>> >> ).
>> >>>> We log client warnings (if enabled) but ignore any detailed error
>> >> message
>> >>>> received from the server; it would be good to talk about client
>> >>>> integrations and how users are informed of issues in more detail.
>> >>>
>> >>>
>> >>> I have updated the CEP to include those thresholds among the ones that
>> >>> could be migrated once we have the guardrails framework ready. I have
>> >> also
>> >>> mentioned the usage of internal messaging to be able to propagate the
>> >>> outcome of guardrails triggered on nodes that are not the coordinator,
>> >> and
>> >>> the need of making changes 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

[VOTE] CEP-3: Guardrails

[Andrés de la Peña]

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 be open for 72 hours.
A vote passes if there are at least three binding +1s and no binding vetoes.

Thanks,

Re: [VOTE] CEP-3: Guardrails

[Andrés de la Peña]

The vote passes with 12 +1 votes and no -1 votes.

I'll shortly open some tickets to start implementing guardrails.

On Fri, 12 Nov 2021 at 14:51, Joshua McKenzie  wrote:

> +1
>
> On Thu, Nov 11, 2021 at 12:06 PM David Capwell  >
> wrote:
>
> > +1
> >
> > > 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
> > >>
> > >> On Thu, Nov 11, 2021 at 5:30 AM Andrés de la Peña <
> adelap...@apache.org
> > >
> > >> wrote:
> > >>
> > >>> 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 be open for 72 hours.
> > >>> A vote passes if there are at least three binding +1s and no binding
> > >>> vetoes.
> > >>>
> > >>> Thanks,
> > >>>
> > >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: [VOTE] CEP-17: SSTable format API

[Andrés de la Peña]

+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
> >
> > Discussion:
> >
> https://lists.apache.org/thread.html/r636bebcab4e678dbee042285449193e8e75d3753200a1b404fcc7196%40%3Cdev.cassandra.apache.org%3E
> >
> > The vote will be open for 72 hours.
> > A vote passes if there are at least three binding +1s and no binding
> vetoes.
> >
> > Regards,
> > Branimir
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Formalizing our CI process

[Andrés de la Peña]

+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 *circleci tests* to run
> before merging, and the ci-cassandra jenkins is canonical post excepting
> release blocking.
>
> small nits
>
> Tweaked those two little bits as those are non-controversial.
>
> All three edits are clarifications and not changes so no change to the
> vote.
>
> Keep the feedback coming!
>
> ~Josh
>
> On Tue, Jan 11, 2022 at 8:27 AM Mick Semb Wever  wrote:
>
>>
>>
>> On Mon, 10 Jan 2022 at 20:00, Joshua McKenzie 
>> wrote:
>>
>>> Wiki draft article here:
>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530280
>>>
>>
>>
>> +1
>>
>> small nits:
>> - none of the other confluence pages use the "Apache" prefix
>> - can it reference the CI Systems page please
>> - post-vote: maybe the release process doc needs an update?
>> https://cassandra.apache.org/doc/latest/development/release_process.html
>>
>>

Re: [VOTE] Formalizing our CI process

[Andrés de la Peña]

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 green CI as a resting state so we are ready in
> the event of an emergency.
>
> Test results that we can trust help us ship urgent fixes safely. If I were
> a user and had an urgent need to ramp a new build (e.g., if Apache
> Cassandra were affected by log4j), I would be very concerned about a
> fleet-wide deploy of a distributed database release with failing tests.
>
> But in both cases, +1nb. :)
>
> – Scott
>
> On Jan 12, 2022, at 11:22 AM, David Capwell  wrote:
>
>
> +1
>
> On Jan 12, 2022, at 8:39 AM, Joseph Lynch  wrote:
>
> On Wed, Jan 12, 2022 at 3:25 AM Berenguer Blasi
>  wrote:
>
>
> jenkins CI was at 2/3 flakies consistently post 4.0 release.
>
>
> That is really impressive and I absolutely don't mean to downplay that
> achievement.
>
> Then things broke and we've been working hard to get back to the 2/3
> flakies. Most
> current failures imo are timeuuid C17133 or early termination of process
> C17140 related afaik. So getting back to the 2/3 'impossible' flakies
> should be doable and a reasonable target (famous last words...). My 2cts.
>
>
> I really appreciate all the work folks have been doing to get the
> project to green, and I support the parts of the proposal that try to
> formalize methods to try to keep us there. I am only objecting to #2
> in the proposal where we have a non-negotiable gate on tests before a
> release.
>
> -Joey
>
>
>

Re: [VOTE] Release dtest-api 0.0.12

[Andrés de la Peña]

+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:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.12
> >
> > Candidate SHA:
> >
> https://github.com/apache/cassandra-in-jvm-dtest-api/commit/207d6cee2d01552f794d322ec05a7577bcab08e0
> > tagged with 0.0.12
> >
> > Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1252/org/apache/cassandra/dtest-api/0.0.12/
> >
> > Key signature: A4C465FEA0C552561A392A61E91335D77E3E87CB
> >
> > Changes since last release:
> >   * CASSANDRA-17214:Add IInstance.isValid() with default true return
> value
> >
> >
> > The vote will be open for 24 hours. 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.
>

Re: Have we considered static type checking for our python libs?

[Andrés de la Peña]

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 14:02, Joshua McKenzie  wrote:

> Could be a very fruitful source of LHF tickets to highlight in the
> biweekly email and would be pretty trivial to integrate this into the build
> lead role (getting an epic and jira tickets created to port tests over,
> etc).
>
> we can run our tests much more quickly, and debug failures much more
>> easily.
>
> Please Yes. If we can get away from python upgrade tests I think all our
> lives would be improved.
>
> I like it.
>
>
> On Wed, Jan 26, 2022 at 8:42 AM bened...@apache.org 
> wrote:
>
>> We could set this as a broad goal of the project, and like the build lead
>> role could each volunteer to adopt a test every X weeks. We would have
>> migrated in no time, I expect, with this kind of concerted effort, and
>> might not even notice a significant penalty to other ongoing work.
>>
>>
>>
>> Last time I ported a dtest it was a very easy thing to do.
>>
>>
>>
>> I might even venture to predict that it might payoff with lower
>> development overhead, as we can run our tests much more quickly, and debug
>> failures much more easily.
>>
>>
>>
>> *From: *Joshua McKenzie 
>> *Date: *Wednesday, 26 January 2022 at 13:40
>> *To: *dev 
>> *Subject: *Re: Have we considered static type checking for our python
>> libs?
>>
>> I have yet to encounter this class of problem in the dtests.
>>
>> It's more about development velocity and convenience than about
>> preventing defects in our case, since we're not abusing duck-typing
>> everywhere. Every time I have to work on python dtests (for instance, when
>> doing build lead work and looking at flaky tests) it's a little irritating
>> and I think of this.
>>
>>
>>
>>  I would hate to expend loads of effort modernising them when the same
>> effort could see them superseded by much better versions of the same test.
>>
>> I completely agree, however this is something someone would have to take
>> on as an effort and I don't believe I've seen anybody step up yet. At the
>> current rate we're going to be dragging along the python dtests into
>> perpetuity.
>>
>>
>>
>>
>>
>> On Wed, Jan 26, 2022 at 8:16 AM bened...@apache.org 
>> wrote:
>>
>> I was sort of hoping we would retire the python dtests before long, at
>> least in large part (probably not ever entirely, but 99%).
>>
>>
>>
>> I think many of them could be migrated to in-jvm dtests without much
>> effort. I would hate to expend loads of effort modernising them when the
>> same effort could see them superseded by much better versions of the same
>> test.
>>
>>
>>
>>
>>
>> *From: *Joshua McKenzie 
>> *Date: *Wednesday, 26 January 2022 at 12:59
>> *To: *dev 
>> *Subject: *Have we considered static type checking for our python libs?
>>
>> Relevant links:
>>
>> 1) Optional static typing for python:
>> https://docs.python.org/3/library/typing.html
>>
>> 2) Mypy static type checker for python: https://github.com/python/mypy
>>
>>
>>
>> So the question - has anyone given any serious thought to introducing
>> type hints and a static type checker in ccm and python dtests? A search on
>> dev ponymail doesn't turn up anything.
>>
>>
>>
>> I've used it pretty extensively in the past and found it incredibly
>> helpful combined with other linters in surfacing troublesome edge cases,
>> and also found it accelerated development quite a bit.
>>
>>
>>
>> Any thoughts on the topic for or against?
>>
>>
>>
>> ~Josh
>>
>>

Re: [VOTE] CEP-19: Trie memtable implementation

[Andrés de la Peña]

+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
>
> On Feb 16, 2022, at 7:30 AM, Josh McKenzie  wrote:
>
> 
> +1
>
> On Wed, Feb 16, 2022, at 7:33 AM, Ekaterina Dimitrova wrote:
>
> +1nb
>
> On Wed, 16 Feb 2022 at 7:30, Brandon Williams  wrote:
>
> +1
>
> On Wed, Feb 16, 2022 at 3:00 AM Branimir Lambov 
> wrote:
> >
> > Hi everyone,
> >
> > I'd like to propose CEP-19 for approval.
> >
> > Proposal:
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation
> > Discussion:
> https://lists.apache.org/thread/fdvf1wmxwnv5jod59jznbnql23nqosty
> >
> > 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.
> >
> > Thank you,
> > Branimir
>
>
>

Re: [DISCUSS] Should we deprecate / freeze python dtests

[Andrés de la Peña]

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 are environmentally
> more challenging to work with, causing many problems on local and remote
> machines. They are harder to debug, slower, flakier, and mostly less
> sophisticated.
>
>
>
> > all focus on getting the in-jvm framework robust enough to cover
> edge-cases
>
>
>
> Would be great to collect gaps. I think it’s just vnodes, which is by no
> means a fundamental limitation? There may also be some stuff to do
> startup/shutdown and environmental scripts, that may be a niche we retain
> something like python dtests for.
>
>
>
> > people aren’t familiar
>
>
>
> I would be interested to hear from these folk to understand their concerns
> or problems using in-jvm dtests, if there is a cohort holding off for this
> reason
>
>
>
> > This is going to require documentation work from some of the original
> authors
>
>
>
> I think a collection of template-like tests we can point people to would
> be a cheap initial effort. Cutting and pasting an existing test with the
> required functionality, then editing to suit, should get most people off to
> a quick start who aren’t familiar.
>
>
>
> > Labor and process around revving new releases of the in-jvm dtest API
>
>
>
> I think we need to revisit how we do this, as it is currently broken. We
> should consider either using ASF snapshots until we cut new releases of C*
> itself, or else using git subprojects. This will also become a problem for
> Accord’s integration over time, and perhaps other subprojects in future, so
> it is worth better solving this.
>
>
>
> I think this has been made worse than necessary by moving too many
> implementation details to the shared API project – some should be retained
> within the C* tree, with the API primarily serving as the shared API itself
> to ensure cross-version compatibility. However, this is far from a complete
> explanation of (or solution to) the problem.
>
>
>
>
>
>
>
> *From: *Josh McKenzie 
> *Date: *Monday, 14 March 2022 at 12:11
> *To: *dev@cassandra.apache.org 
> *Subject: *[DISCUSS] Should we deprecate / freeze python dtests
>
> I've been wrestling with the python dtests recently and that led to some
> discussions with other contributors about whether we as a project should be
> writing new tests in the python dtest framework or the in-jvm framework.
> This discussion has come up tangentially on some other topics, including
> the lack of documentation / expertise on the in-jvm framework
> dis-incentivizing some folks from authoring new tests there vs. the
> difficulty debugging and maintaining timer-based, sleep-based
> non-deterministic python dtests, etc.
>
>
>
> I don't know of a place where we've formally discussed this and made a
> project-wide call on where we expect new distributed tests to be written;
> if I've missed an email about this someone please link on the thread here
> (and stop reading! ;))
>
>
>
> At this time we don't specify a preference for where you write new
> multi-node distributed tests on our "development/testing" portion of the
> site and documentation:
> https://cassandra.apache.org/_/development/testing.html
>
>
>
> The primary tradeoffs as I understand them for moving from python-based
> multi-node testing to jdk-based are:
>
> Pros:
>
>1. Better debugging functionality (breakpoints, IDE integration, etc)
>2. Integration with simulator
>3. More deterministic runtime (anecdotally; python dtests _should_ be
>deterministic but in practice they prove to be very prone to environmental
>disruption)
>4. Test time visibility to internals of cassandra
>
> Cons:
>
>1. The framework is not as mature as the python dtest framework (some
>functionality missing)
>2. Labor and process around revving new releases of the in-jvm dtest
>API
>3. People aren't familiar with it yet and there's a learning curve
>
>
>
> So my bid here: I personally think we as a project should freeze writing
> new tests in the python dtest framework and all focus on getting the in-jvm
> framework robust enough to cover edge-cases that might still be causing new
> tests to be written in the python framework. This is going to require
> documentation work from some of the original authors of the in-jvm
> framework as well as folks currently familiar with it and effort from those
> of us not yet intimately familiar with the API to get to know it, however I
> believe the long-term benefits to the project will be well worth it.
>
>
>
> We could institute a pre-commit check that warns on a commit increasing
> our raw count of python dtests to help provide process-based visibility to
> this change in direction for the project's testing.
>
>
>
> So: what do we think?
>
>
>

Re: [FOR REVIEW] Blog post: An Interview with Project Contributor, Lorina Poland

[Andrés de la Peña]

+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 Interview with Project
>> Contributor, Lorina Poland
>>
>> Looks good to me! 🍻
>>
>>
>>
>> On Wed, 16 Mar 2022 at 08:17, Chris Thornett  wrote:
>>
>> As requested, I'm posting content contributions for community review on
>> the ML for those that might not spot them on Slack.
>>
>>
>>
>> We're currently mid-review for our first contributor Q&A which is with
>> Lorina Poland:
>>
>>
>> https://docs.google.com/document/d/1nnH4V1XvTcfTeeUdZ_mjSxlNlWTbSXFu_qKtJRQUFBk/edit.
>> Please add edits or suggests as comments.
>>
>>
>>
>> Thanks!
>>
>> --
>>
>>
>>
>> Chris Thornett
>>
>> senior content strategist, Constantia.io
>>
>> ch...@constantia.io
>>
>>

Re: Welcome Aleksandr Sorokoumov as Cassandra committer

[Andrés de la Peña]

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:
>
>> Congratulations Alex, well deserved! :-)
>>
>> Em qua., 16 de mar. de 2022 às 10:15, Benjamin Lerer 
>> escreveu:
>>
>>> The PMC members are pleased to announce that Aleksandr Sorokoumov has
>>> accepted
>>> the invitation to become committer.
>>>
>>> Thanks a lot, Aleksandr , for everything you have done for the project.
>>>
>>> Congratulations and welcome
>>>
>>> The Apache Cassandra PMC members
>>>
>>

Re: Call for Volunteers - Build Lead

[Andrés de la Peña]

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 people already participated. (Thank you!) Most failures in Butler have
> respective tickets linked to them, many tickets were even already closed.
>
> This email is to remind you about this initiative. Don't be shy to
> volunteer participation in the rotation. :-) Josh and Brandon did the heavy
> lifting with opening the most tickets during  the first two weeks so now
> primarily brand new failures need attention. Also, I should acknowledge
> that many people worked on failures, thank you for doing it!
>
> Feel free to add yourself to the rotation schedule here -
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199527692
> We don't have any names populated after this week.
>
> Thank you in advance for all your help!
>
> Ekaterina Dimitrova
>
>
>

Re: Pluggability improvements in 4.1

[Andrés de la Peña]

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. can be
based on things like, for example, who is running the guarded query.

On Tue, 26 Apr 2022 at 21:12, Henrik Ingo  wrote:

> Hi all
>
> As one would expect, I've been involved in several discussions lately on
> what is going to make it into 4.1, versus what patches unfortunately won't.
>
> In particular debating this with Patrick McFaddin we realized that a big
> theme in 4.1 appears to be a huge number of pluggability improvements. So
> the intent of this email is to take an inventory of all new plugin APIs I'm
> aware of, and invite the community to add to the list where I'm not aware
> of some work.
>
>
> CEP-9
> 
> Pluggable SSLContext. Allows to store SSL certs and secrets elsewhere than
> in files. Supplies an example implementation for storing as Kubernetes
> Secret.
>
>
> *CEP-10*
> 
> SimpleCondition, Semaphore, CountDownLatch, BlockingQueue, etc
> Executors, futures, starting threads, etc - including important
> improvements to consistency of approach in the codebase
> The use of currentTimeMillis and nanoTime
> The replacement of java.io.File with a wrapper on java.nio.files.Path
> providing an ergonomic API, and some improvements to consistency of file
> handling
> Support for alternative streaming implementations
> Improvements to the dtest API to support necessary functionality
>
> Commentary: Of the above at least the Path and alternative streaming
> implementations seem like significant APIs that can be used for much more
> than just fault injection. In fact, I believe java.nio.files.Path is what
> we use in Astra Serverless to send files to S3 instead of local filesystem.
>
>
> *CEP-11*
> 
> Pluggable memtable
>
> Commentary: While we won't have any new memtable implementations in 4.1,
> it is a goal to merge the memtable API this week. Notably, since this is
> designed to support also persistent memtables (ie memtable on persistent
> memory), this new API could essentially be seen as a full blown storage
> engine API.
>
>
> *CASSANDRA-17044* 
> Pluggable schema management
>
> I hear rumors someone may be working on a new schema management
> implementation?
>
>
> (Just for completeness, CASSANDRA-17058
>  pluggable cluster
> membership is not merged.)
>
> CEP-16
> 
> While client side, worth mentioning: Pluggable auth for CQLSH
>
>
>
> If there are more that I don't know about, please reply and add to the
> list.
>
> henrik
>
> --
>
> Henrik Ingo
>
> +358 40 569 7354 <358405697354>
>
> [image: Visit us online.]   [image: Visit us
> on Twitter.]   [image: Visit us on
> YouTube.]
> 
>   [image: Visit my LinkedIn profile.]
> 
>

Re: [VOTE] Release Apache Cassandra 3.0.27

[Andrés de la Peña]

+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:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.27-tentative
> > Maven Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1267/org/apache/cassandra/cassandra-all/3.0.27/
> >
> > The Source and Build Artifacts, and the Debian and RPM packages and
> > repositories, are available here:
> > https://dist.apache.org/repos/dist/dev/cassandra/3.0.27/
> >
> > 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]: CHANGES.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.27-tentative
> > [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.27-tentative
>
>

Re: [VOTE] Release Apache Cassandra 3.11.13

[Andrés de la Peña]

+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:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.13-tentative
> > Maven Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1268/org/apache/cassandra/cassandra-all/3.11.13/
> >
> > The Source and Build Artifacts, and the Debian and RPM packages and
> > repositories, are available here:
> > https://dist.apache.org/repos/dist/dev/cassandra/3.11.13/
> >
> > 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]: CHANGES.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.13-tentative
> > [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.13-tentative
>
>

Re: [VOTE] Release Apache Cassandra 4.0.4 (take2)

[Andrés de la Peña]

+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:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.4-tentative
> > Maven Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1270/org/apache/cassandra/cassandra-all/4.0.4/
> >
> > The Source and Build Artifacts, and the Debian and RPM packages and
> > repositories, are available here:
> > https://dist.apache.org/repos/dist/dev/cassandra/4.0.4/
> >
> > 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]: CHANGES.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.4-tentative
> > [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.4-tentative
>
>