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

[Aleksey Yeshchenko]

+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: Issue when creating a stream session

[Aleksey Yeshchenko]

Indeed, it is safe to clean up now.

Normally we prefer to do cleanups like that on trunk only, but I’d say feel 
free to remove this dead code in 4.0+ if that’s the branch you are targeting in 
CASSANDRA-17199.

> On 19 Dec 2022, at 03:53, Yuki Morishita  wrote:
> 
> I dug the git history and it looks like CASSANDRA-3569 
>  changed to not 
> register to Gossip.
> https://github.com/apache/cassandra/commit/0f2d7d0b9540efa3ea3dfe4f8270c3635afdc63c
> (It removed the `register` part, not the `unregister` part though.)
> 
> Since StreamSession is no longer registered to nor unregistered from 
> Gosipper, I say the current "implements" code
> is a dead code and we can remove it safely.
> 
> 
> On Sat, Dec 17, 2022 at 4:57 AM David Capwell  > wrote:
>> This sounds like a bug to me, but would be good to get feedback from others 
>> who have touched Streaming…
>> 
>> Repair will fail if membership notifies that a participate node was removed, 
>> so I think it makes sense for Streaming to also follow this behavior.
>> 
>>> On Dec 14, 2022, at 1:22 PM, Natnael Adere >> > wrote:
>>> 
>>> To give more context, StreamSession is not listening to Gossip for 
>>> membership changes. Although it implements an interface for listening to 
>>> membership changes, we do not register with Gossip and, therefore, never 
>>> get these changes. This results in the IEndpointStateChangeSubscriber 
>>> interface being dead code. My question is wether or not this is a bug to be 
>>> fixed or code to delete. Currently, streaming does not fail on membership 
>>> changes because of this problem. If Gossip says that a node was removed or 
>>> restarted, should we fail the stream or not?
>>> 
>>> Thanks,
>>> Natnael
 On Dec 14, 2022, at 1:39 PM, Natnael Adere >>> > wrote:
 
 Hello,
 
 I am working on CASSANDRA-17199 
  and testing for 
 this ticket has uncovered some issues with streaming. When creating a 
 StreamSession we have an intent for to listen but that never happens. My 
 concern is wether or not we should we listen and make sure the interface 
 it implements is not dead code or delete the interface and all of its 
 methods. Our style guide requires no dead code so this might be 
 intentional, but when testing we see that StreamSession not listening. If 
 it is intentional then I suppose we make sure that we are listening. Any 
 opinions on what to do in this scenario?
 
 
 (PROBLEM) The project compiles in both scenarios:
 public class StreamSession implements IEndpointStateChangeSubscriber
 
 public class StreamSession //implements IEndpointStateChangeSubscriber
 
 
 Thanks,
 
 Natnael
>>> 
>> 

Re: Should we change 4.1 to G1 and offheap_objects ?

[Aleksey Yeshchenko]

Switching a major default in a minor release is way worse than doing it in a GA 
- less notice and visibility, many folks don’t even read minor version NEWS.txt 
before upgrading.

Trunk is fine by me though.

> On 12 Jan 2023, at 13:14, Mick Semb Wever  wrote:
> 
>> Ok, wrt G1 default, this is won't go ahead for 4.1-rc1
>> 
>> We can revisit it for 4.1.x
>> 
>> We have a lot of voices here adamantly positive for it, and those of us that 
>> have done the performance testing over the years know why. But being called 
>> to prove it is totally valid, if you have data to any such tests please add 
>> them to the ticket 18027
> 
> 
> Revisiting. Are there any vetoes to making G1 the default (and
> updating the G1 settings, see the patch on
> https://issues.apache.org/jira/browse/CASSANDRA-18027 ) for 4.1.1 ?
> 
> IIUC , the summary of this thread till now was: there were no vetoes
> to the change in trunk, but there were vetoes to 4.1.0 (because we
> were inside the beta to GA window), and there was a desire to have
> benchmarking data presented.
> 
> WRT benchmarking, we have a separate thread for performance testing in
> the project.  The ticket admittedly does not do its due diligence on
> data presentation and analysis of smaller heaps: a precedent we should
> be creating; but instead relies upon experience from many. Are we ok
> with this this time around, or shall the patch only be applied to
> trunk (where we have no choice w/ jdk17 landing)?

Re: Merging CEP-15 to trunk

[Aleksey Yeshchenko]

What Benedict says is that the commits into cassandra/cep-15-accord and 
cassandra-accord/trunk branch have all been vetted by at least two committers 
already. Each authored by a Cassandra committer and then reviewed by a 
Cassandra committer. That *is* our bar for merging into Cassandra trunk.

> On 20 Jan 2023, at 12:31, Mick Semb Wever  wrote:
> 
>> 
>> These tickets have all met the standard integration requirements, so I’m 
>> just unclear what “higher pre-commit gateway” you are referring to.
> 
> 
> A merge into trunk deserves extra eyeballs than a merge into a feature branch.
> 
> We can refer to this as a "higher pre-commit gateway" or a "second pass".  
> Either way I believe it is a good thing.

Re: Merging CEP-15 to trunk

[Aleksey Yeshchenko]

More eyes are of course always welcome.

That said, there haven’t been many volunteers so far, despite its development 
going on for many months now, in the open, in official ASF repos. I suspect 
mainly because it’s pretty hard and not exactly very fun (speaking from 
experience).

> If it happens / if anyone is interested. But if nobody expresses any concerns 
> or asks for time to look into something specific, then I agree that the 
> reviews that have already happened in the feature branch are sufficient and  
> there isn't a need for a new full blown review.

That sounds perfectly reasonable to me.

Truth is, next major release is pretty far away. This is not an attempt to 
fast-track a major change right before a release vote. Anything can be 
reverted, anything can be modified, and many things will be before now and then 
- there is a pretty long list of work remaining to be done.

The CEP was voted on, development is progressing along the lines of the CEP, 
and any extra review on top of the mandated (and objectively already cleared) 
bar can be performed on trunk commits just as easily after the merge. Many 
months ahead for any volunteers to take a look at the work already done and the 
work yet to come and raise any issues.

The sooner it’s in trunk, the more eyes it will draw, IMO, if you are right 
about most contributors not having paid attention to a feature branch.

> On 20 Jan 2023, at 15:34, Henrik Ingo  wrote:
> 
> I might be completely off, but I think what others are referring to here is 
> that 2 committers is the minimum bar, and for any commit there could be other 
> contributors wishing to review some part or even in full what is being 
> merged, and we would always allow for that, within reasonable time limits.
> 
> Since most contributors would not have paid attention to a feature branch, 
> the result is that that additional review happens now. If it happens / if 
> anyone is interested. But if nobody expresses any concerns or asks for time 
> to look into something specific, then I agree that the reviews that have 
> already happened in the feature branch are sufficient and  there isn't a need 
> for a new full blown review.
> 
> As far as I can tell, this email thread is exactly that process and I imagine 
> was at least one of the reasons to send this heads up email?
> 
> henrik
> 
> On Fri, Jan 20, 2023 at 5:23 PM Aleksey Yeshchenko  <mailto:alek...@apple.com>> wrote:
>> What Benedict says is that the commits into cassandra/cep-15-accord and 
>> cassandra-accord/trunk branch have all been vetted by at least two 
>> committers already. Each authored by a Cassandra committer and then reviewed 
>> by a Cassandra committer. That *is* our bar for merging into Cassandra trunk.
>> 
>>> On 20 Jan 2023, at 12:31, Mick Semb Wever >> <mailto:m...@datastax.com>> wrote:
>>> 
>>>> 
>>>> These tickets have all met the standard integration requirements, so I’m 
>>>> just unclear what “higher pre-commit gateway” you are referring to.
>>> 
>>> 
>>> A merge into trunk deserves extra eyeballs than a merge into a feature 
>>> branch.
>>> 
>>> We can refer to this as a "higher pre-commit gateway" or a "second pass".  
>>> Either way I believe it is a good thing.
>> 
> 
> 
> -- 
> 
> Henrik Ingo
> c. +358 40 569 7354 
> w. www.datastax.com <http://www.datastax.com/>
>  <https://www.facebook.com/datastax>   <https://twitter.com/datastax>   
> <https://www.linkedin.com/company/datastax/>   <https://github.com/datastax/>

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

[Aleksey Yeshchenko]

Bringing light to new proposed APIs no less important - if not more, for 
reasons already mentioned in this thread. For it’s not easy to change them 
later.

Voting B.

> On 2 Feb 2023, at 10:15, Andrés de la Peña  wrote:
> 
> 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.

Re: Implicitly enabling ALLOW FILTERING on virtual tables

[Aleksey Yeshchenko]

Just make virtual table implementations decide?

Add a method to VirtualTable interface to indicate if this is desirable, and 
call it a day? 

> On 6 Feb 2023, at 09:41, Benjamin Lerer  wrote:
> 
> Making ALLOW FILTERING a table option implies giving the right to the person 
> creating the table the ability to change the way the server will behave for 
> that table which might not be something that every C* operator wants. Of 
> course we can allow operators to controle that through the ALLOW FILTERING 
> guardrail. At that point we would also need to have a default setting for the 
> entire database.
> 
> Le ven. 3 févr. 2023 à 23:44, Miklosovic, Stefan 
> mailto:stefan.mikloso...@netapp.com>> a écrit :
>> This is the draft for FILTERING ON|OFF in shell.
>> 
>> I would say this is the most simple solution.
>> 
>> We may still consider table option but what do you think about having it 
>> simply just set via shell?
>> 
>> https://github.com/apache/cassandra/pull/2141/files
>> 
>> 
>> From: Josh McKenzie mailto:jmcken...@apache.org>>
>> Sent: Friday, February 3, 2023 23:39
>> To: dev
>> Subject: Re: Implicitly enabling ALLOW FILTERING on virtual tables
>> 
>> 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.
>> 
>> 
>> 
>> they would start to set ALLOW FILTERING here and there in order to not think 
>> twice about their data model so they can just call it a day.
>> Setting this on a per-table basis or having users set this on specific 
>> queries that hit tables and forgetting they set it are 6 of one and 
>> half-a-dozen of another.
>> 
>> I like the table property idea personally. That communicates an intent about 
>> the data model and expectation of the size and usage of data in the modeling 
>> of the schema that embeds some context and intent there's currently no 
>> mechanism to communicate.
>> 
>> On Fri, Feb 3, 2023, at 5:00 PM, Miklosovic, Stefan wrote:
>> Yes, there would be discrepancy. I do not like that either. If it was only 
>> about "normal tables vs virtual tables", I could live with that. But the 
>> fact that there are going to be differences among vtables themselves, that 
>> starts to be a little bit messy. Then we would need to let operators know 
>> what tables are always allowed to be filtered on and which do not and that 
>> just complicates it. Putting that information to comment so it is visible in 
>> DECSCRIBE is nice idea.
>> 
>> That flag we talk about ... that flag would be used purely internally, it 
>> would not be in schema to be gossiped.
>> 
>> Also, I am starting to like the suggestion to have something like ALLOW 
>> FILTERING ON in CQLSH so it would be turned on whole CQL session. That 
>> leaves tables as they are and it should not be a big deal for operators to 
>> set. We would have to make sure to add "ALLOW FILTERING" clause to every 
>> SELECT statement (to virtual tables only?) a user submits. I am not sure if 
>> this is doable yet though.
>> 
>> 
>> From: David Capwell > > >>
>> Sent: Friday, February 3, 2023 22:42
>> To: dev
>> Cc: Maxim Muzafarov
>> Subject: Re: Implicitly enabling ALLOW FILTERING on virtual tables
>> 
>> 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 don't think the assumption that "virtual tables will always be small and 
>> always fit in memory" is a safe one.
>> 
>> Agree, there is a repair ticket to have the coordinating node do network 
>> queries to peers to resolve the table (rather than operator querying 
>> everything, allow the coordinator node to do it for you)… so this assumption 
>> may not be true down the line.
>> 
>> I could be open to a table property that says ALLOW FILTERING on by default 
>> or not… then we can pick and choose vtables (or have vtables opt-out)…. I 
>> kinda like like the lack of consistency with this approach though
>> 
>> On Feb 3, 2023, at 11:24 AM, 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

Re: [VOTE] CEP-21 Transactional Cluster Metadata

[Aleksey Yeshchenko]

+1

> On 6 Feb 2023, at 17:24, Benedict  wrote:
> 
> +1
> 
>> On 6 Feb 2023, at 16:17, Brandon Williams  wrote:
>> 
>> 
>> +1
>> 
>> On Mon, Feb 6, 2023, 10: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: [DISCUSS] Allow UPDATE on settings virtual table to change running configuration

[Aleksey Yeshchenko]

FWIW most of those volatile fields, if not in fact all of them, should NOT be 
volatile at all. Someone started the trend and most folks have been copycatting 
or doing the same for consistency with the rest of the codebase.

Please definitely don’t rely on that.

> On 21 Feb 2023, at 21:06, Maxim Muzafarov  wrote:
> 
> 1. Rely on the volatile keyword in front of fields in the Config class;
> 
> I would say this is the most confusing option for me because it
> doesn't give us all the guarantees we need, and also:
> - We have no explicit control over what exactly we expose to a user.
> When we modify the JMX API, we're implementing a new method for the
> MBean, which in turn makes this action an explicit exposure;
> - The volatile keyword is not the only way to achieve thread safety,
> and looks strange for the public API design point;
> - A good example is the setEnableDropCompactStorage method, which
> changes the volatile field, but is only visible for testing purposes;

Re: [DISCUSS] Allow UPDATE on settings virtual table to change running configuration

[Aleksey Yeshchenko]

Could maybe be an issue for some really tight unit tests. In actual use the 
updates to those fields will be globally visible near instantly without 
volatile keyword.

> On 22 Feb 2023, at 13:17, Benjamin Lerer  wrote:
> 
> I have seen issues with some updatable parameters which were missing the 
> volatile keyword.
> 
> Le mer. 22 févr. 2023 à 11:36, Aleksey Yeshchenko  <mailto:alek...@apple.com>> a écrit :
>> FWIW most of those volatile fields, if not in fact all of them, should NOT 
>> be volatile at all. Someone started the trend and most folks have been 
>> copycatting or doing the same for consistency with the rest of the codebase.
>> 
>> Please definitely don’t rely on that.
>> 
>>> On 21 Feb 2023, at 21:06, Maxim Muzafarov >> <mailto:mmu...@apache.org>> wrote:
>>> 
>>> 1. Rely on the volatile keyword in front of fields in the Config class;
>>> 
>>> I would say this is the most confusing option for me because it
>>> doesn't give us all the guarantees we need, and also:
>>> - We have no explicit control over what exactly we expose to a user.
>>> When we modify the JMX API, we're implementing a new method for the
>>> MBean, which in turn makes this action an explicit exposure;
>>> - The volatile keyword is not the only way to achieve thread safety,
>>> and looks strange for the public API design point;
>>> - A good example is the setEnableDropCompactStorage method, which
>>> changes the volatile field, but is only visible for testing purposes;
>> 

Re: [DISCUSS] Next release date

[Aleksey Yeshchenko]

Don’t need to revert it so long as the feature they are for is not enabled by 
default. Or, if it’s a bit away from being useful enough to even test - mad 
hard-disabled without a way to enable.

> On 1 Mar 2023, at 16:34, Henrik Ingo  wrote:
> 
> already merged 3 patches, but still has 2 to go? Can we allow extra time to 
> merge the last two, or do we work on reverting the first 3? (Obviously not 
> the latter...)

Re: [DISCUSS] Drop support for sstable formats m* (in trunk)

[Aleksey Yeshchenko]

Raising messaging service minimum, I have a less strong opinion on, but on 
dropping m* sstable code I’m strongly -1.

1. This is code on a rarely touched path
2. It’s very stable and battle tested at this point
3. Removing it doesn’t reduce much complexity at all, just a few branches are 
affected
4. Removing code comes with risk
5. There are third-party tools that I know of which benefit from a single C* 
jar that can read all relevant stable versions, and relevant here includes 3.0 
ones

Removing a little of battle-tested reliable code and a tinier amount of 
complexity is not, to me, a benefit enough to justify intentionally breaking 
perfectly good and useful functionality.

Oh, to add to that - if an operator wishes to upgrade from 3.0 to 5.0, and we 
don’t support it directly, I think most of us are fine with the requirement to 
go through a 4.X release first. But it’s one thing to require a two rolling 
restarts (3.0 to 4.0, 4.0 to 5.0), it’s another to require the operator to 
upgrade every single m* sstable to n*. Especially when we have perfectly 
working code to read those. That’s incredibly wasteful.

AY

> On 13 Mar 2023, at 22:54, Mick Semb Wever  wrote:
> 
> If we do not recommend and do not test direct upgrades from 3.x to
> 5.x, we can clean up a fair bit by removing code related to sstable
> formats m*, as Cassandra versions 4.x and  5.0 are all on sstable
> formats n*.
> 
> We don't allow mixed-version streaming, so it's not possible today to
> stream any such older sstable format between nodes. This
> compatibility-break impacts only node-local and/or offline.
> 
> Some arguments raised to keep m* sstable formats are:
> - offline cluster upgrade, e.g. direct from 3.x to 5.0,
> - single-invocation sstableupgrade usage
> - third-party tools based on the above
> 
> Personally I am not in favour of keeping, or recommending users use,
> code we don't test.
> 
> An _example_ of the code that can be cleaned up is in the patch
> attached to the ticket:
> CASSANDRA-18312 – Drop support for sstable formats before `na`
> 
> What do you think?

Re: Should we cut some new releases?

[Aleksey Yeshchenko]

+1

> On 14 Mar 2023, at 05:50, Berenguer Blasi  wrote:
> 
> +1
> 
> On 13/3/23 21:25, Jacek Lewandowski wrote:
>> +1
>> 
>> pon., 13 mar 2023, 20:36 użytkownik Miklosovic, Stefan 
>> mailto:stefan.mikloso...@netapp.com>> napisał:
>>> Yes, I was waiting for CASSANDRA-18125 to be in.
>>> 
>>> I can release 4.1.1 to staging tomorrow morning CET if nobody objects that.
>>> 
>>> Not sure about 4.0.9. We released 4.0.8 just few weeks ago. I would do 
>>> 4.1.1 first.
>>> 
>>> 
>>> From: Ekaterina Dimitrova >> >
>>> Sent: Monday, March 13, 2023 18:12
>>> To: dev@cassandra.apache.org 
>>> Subject: Re: Should we cut some new releases?
>>> 
>>> 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.
>>> 
>>> 
>>> 
>>> +1
>>> 
>>> On Mon, 13 Mar 2023 at 12:23, Benjamin Lerer >> >> >> wrote:
>>> Hi everybody,
>>> 
>>> Benedict and Jon recently committed the patch for 
>>> CASSANDRA-18125 
>>> which fixes some serious problems at the memtable/flush level. Should we 
>>> consider cutting some releases that contain this fix?

Re: [DISCUSS] Drop support for sstable formats m* (in trunk)

[Aleksey Yeshchenko]

I’m not sure we have an explicit rule at the moment. Would probably based on 
calendar time in addition to release versions if we had one.

Addressing these on case by case basis for now is fine IMO.

I’d say the general principle should be treat extended compatibility (between 
releases in general and subcomponents) should be treated more as a feature and 
less as a liability. In this particular case you have compatibility by default 
by doing nothing, it’s not a huge complexity burden, it’s a tiny amount of 
code, it has clear value, and you have to get out of your way to actually 
cripple it and remove the compatibility. Bad idea.

> On 14 Mar 2023, at 15:04, Jacek Lewandowski  
> wrote:
> 
> Do we consider it as an occasional exception to the rule or we will define a 
> rule which explicitly says how many versions the user can expect to be 
> supported?

Re: [DISCUSS] Drop support for sstable formats m* (in trunk)

[Aleksey Yeshchenko]

> Saying that there is never any complexity and we should keep formats in 
> perpetuity, and I'm sitting here having a heart attack, srsly. 

Nobody is claiming that. Don’t let a straw man give you a heart attack.

> Though I _always_ recommend users upgrade all sstables, before and after 
> every major upgrade.  But I recognise how easy it is to forget or err in that 
> process, and we don't need to punish operators unnecessarily. 

Bit arrogant to call this an error. An operator might have good reasons to not 
do this. Clusters can be quite large, after all.

> Again, I would always recommend a backup before each major upgrade, and I 
> would think this has become standard advice.  On sstables residing in 
> storage, and the need to do a full backup, that's another good point, but 
> which I think we might solve in a smarter way (see below).

See above. Also, not seeing the follow up to “see below”.

> I beg to differ on this. We don't test it, and upgrade code gets limited 
> production time.

The code to read -m* sstables has been heavily battle-tested. Luckily for the 
project, there are users who test this *very* thoroughly before upgrading, who 
are incentivised to file bug reports, and are very much capable of fixing them 
while at it.

As for precedent - we (including me) have done a lot of stupid shit over the 
years on this project. Half the time “this is how we’ve historically done X” to 
me is a strong argument to start doing things differently. This is one such 
case.
 
—
AY

> On 17 Mar 2023, at 14:24, Mick Semb Wever  wrote:
> 
> 
> Ok ok, there's a number of strong arguments to keep sstable formats around 
> for much longer than the previous major Cassandra version, I will unset 
> fixVersion on 18312  :-)   
> 
> 
> Taking a look at the history of sstable formats. They were first introduced 
> in version 0.7, and minor versions introduced in version 1.0.3 with hb.
> 
> Looking at when we have dropped support and cleaned up the code for past 
> formats.
> 
>  - Versions before 1.2.5: formats <=ib; were removed in CASSANDRA-5511
> https://github.com/apache/cassandra/commit/7f2c3a8e40f97c626def5c510d77c1da3d9ae926
> 
>  - Version 1.2.5: format ic; were remove in CASSANDRA-6869
> https://github.com/apache/cassandra/commit/8e172c8563a995808a72a1a7e81a06f3c2a355ce
> 
>  - All pre-3.0 formats were removed in CASSANDRA-12716 
> https://github.com/apache/cassandra/commit/4a2464192e9e69457f5a5ecf26c094f9298bf069
>  
> 
> Saying that dropping the n* formats right now is such a small reduction in 
> code, roughly double the size of 6869's patch, I agree with.  Saying that 
> there is never any complexity and we should keep formats in perpetuity, and 
> I'm sitting here having a heart attack, srsly.  I can also appreciate coming 
> up with a good rule of thumb in advance is difficult when we just don't know 
> how many formats there will be and what they will introduce.
> 
> 
> From Aleksey:
> > But it’s one thing to require a two rolling restarts (3.0 to 4.0, 4.0 to 
> > 5.0), it’s another to require the operator to upgrade every single m* 
> > sstable to n*. 
> 
> 
> Good point. 
> 
> Though I _always_ recommend users upgrade all sstables, before and after 
> every major upgrade.  But I recognise how easy it is to forget or err in that 
> process, and we don't need to punish operators unnecessarily.  Also worth 
> noting since 4.x we have `automatic_sstable_upgrade` (which is wisely false 
> by default).
> 
> Question/Suggestion: should we improve gossip to include what the oldest 
> format a node has, and ensure newer versioned node joining fail/warn if it 
> does not support that older format?  That is, should we give a clear signal 
> back to operators that their rolling upgrade is not going to work smoothly, 
> that they are going to hit nodes they will need to stop and do 
> upgradesstables on (leaving them in a state of mix-versions and nodes busy 
> upgrading…)
> 
> 
> From Scott:
>> To expand on the final point he makes re: requiring SSTables be fully 
>> rewritten prior to rev'ing from 4.x to 5.x (if the cluster previously ran 
>> 3.x) –
>> 
>> This would also invalidate incremental backups. Operators would either be 
>> required to perform a full snapshot backup of each cluster to object storage 
>> prior to upgrading from 4.x to 5.x; or to enumerate the contents of all 
>> snapshots from an incremental backup series to ensure that no m*-series 
>> SSTables were present prior to upgrading.
>> 
>> If one failed to take on the work to do so, incremental backup snapshots 
>> would not be restorable to a 5.x cluster if an m*-series SSTable were 
>> present.
> 
> Again, I would always recommend a backup before each major upgrade, and I 
> would think this has become standard advice.  On sstables residing in 
> storage, and the need to do a full backup, that's another good point, but 
> which I think we might solve in a smarter way (see below).
> 
>  
> From Aleksey:
>>> 2. It’s very stable and 

Re: [VOTE] Release Apache Cassandra 4.1.1

[Aleksey Yeshchenko]

+1

> On 17 Mar 2023, at 13:54, 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
> 
> Checked
> - signing correct
> - checksums are correct
> - source artefact builds (JDK 8+11)
> - binary artefact runs (JDK 8+11)
> - debian package runs (JDK 8+11)
> - debian repo runs (JDK 8+11)
> - redhat* package runs (JDK 8+11)
> - redhat* repo runs (JDK 8+11)
> 

Re: CASSANDRA-18247 committed

[Aleksey Yeshchenko]

Hurray!

Great work, thanks for making it happen.

—
AY

> On 20 Mar 2023, at 17:19, Ekaterina Dimitrova  wrote:
> 
> Hi everyone,
> 
> Happy Monday!
> 
> CASSANDRA-18247 was just committed. It adds testing CircleCI configuration 
> for JDK11+JDK17. Full description and how to use it can be found in 
> .circleci/readme.md.
> 
> Please let me know if you have any questions
> 
> Best regards,
> Ekaterina

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

[Aleksey Yeshchenko]

+1

> On 4 Apr 2023, at 16:56, Ekaterina Dimitrova  wrote:
> 
> +1
> 
> On Tue, 4 Apr 2023 at 11:44, Benjamin Lerer  > wrote:
>> +1
>> 
>> Le mar. 4 avr. 2023 à 17:17, Andrés de la Peña > > a écrit :
>>> +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

[Aleksey Yeshchenko]

FYI we support SCHEMA as an alias to KEYSPACE today (have since always). Can 
use CREATE SCHEMA in place of CREATE KEYSPACE, etc. 

> On 4 Apr 2023, at 19:23, Henrik Ingo  wrote:
> 
> I find the Postgres terminology overly complex. Where most SQL databases will 
> have several *databases*, each containing several *tables*, in Postgres we 
> have namespaces, databases, schemas and tables...
> 
> Oracle seems to also use the words database, schema and tables. I don't know 
> if it has namespaces.
> 
> Ah, ok, so SQL Server actually is like Oracle too!
> 
> 
> So in MySQL, referring unambiguously (aka full path) to a table would be:
> 
> SELECT * FROM mydb.mytable;
> 
> Whereas in Postgresql and Oracle and SQL Server you'd have to:
> 
> SELECT * FROM mydb.myschema.mytable;   /* And I don't even know what to 
> do with the namespace! */
> 
> 
> https://www.postgresql.org/docs/current/catalog-pg-namespace.html
> https://www.postgresql.org/docs/current/ddl-schemas.html
> https://docs.oracle.com/database/121/ADMQS/GUID-6E0CE8C9-7DC4-450C-BAE0-2E1CDD882993.htm#ADMQS0821
> https://docs.oracle.com/database/121/ADMQS/GUID-8AC1A325-3542-48A0-9B0E-180D633A5BD1.htm#ADMQS081
> https://learn.microsoft.com/en-us/sql/t-sql/statements/create-schema-transact-sql?view=sql-server-ver16
> https://learn.microsoft.com/en-us/sql/t-sql/statements/create-database-transact-sql?view=sql-server-ver16&tabs=sqlpool
> 
> The Microsoft docs perhaps best explain the role of each: The Database 
> contains the configuration of physical things like where on disk is the 
> database stored. The Schema on the other hand contains "logical" objects like 
> tables, views andprocedures.
> 
> MongoDB has databases and collections. As an easter egg / inside joke, it 
> also supports the command `SHOW TABLES` as a synonym for collections. 
> 
> A TABLESPACE btw is something else completely: 
> https://docs.oracle.com/database/121/ADMQS/GUID-F05EE514-FFC6-4E86-A592-802BA5A49254.htm#ADMQS12053
> 
> 
> 
> Personally I would be in favor of introducing `DATABASE` as a synonym for 
> KEYSPACE. The latter could remain the "official" usage.
> 
> henrik
> 
> 
> On Tue, Apr 4, 2023 at 8:32 PM Jacek Lewandowski  > wrote:
>> While for someone who already knows Cassandra keyspace is something natural, 
>> for newcomers it is yet another concept to understand. 
>> 
>> If namespace is used in PostgreSQL, it sounds even better to me.
>> 
>> Thanks,
>> - - -- --- -  -
>> Jacek Lewandowski
>> 
>> 
>> wt., 4 kwi 2023 o 19:07 Rahul Xavier Singh > > napisał(a):
>>> My 2 cents: 
>>> 
>>> Keeping it keyspace works for me, namespace could be cool also since we 
>>> decide where that namespace exists in relation to Datacenters, etc.  In our 
>>> case, a Keyspace is more similar to a namespace than it is to a database 
>>> since we expect all the UDTs,/UDFs, indexes to refer to only the tables in 
>>> that keyspace/namespace. 
>>> 
>>> Alternatively interesting to observe and throw some fuel into the 
>>> discussion , looking at the Postgres (only because there are many 
>>> distributed databases that are now PG compliant) :
>>> From the interwebs: In PostgreSQL, a schema is a namespace that contains 
>>> named database objects such as tables, views, indexes, data types, 
>>> functions, stored procedures and operators. A database can contain one or 
>>> multiple schemas and each schema belongs to only one database.
>>> 
>>> I used to gripe about this but as a platform gets more complex it is useful 
>>> to organize PG DBs into schemas. In C* world, I found myself doing similar 
>>> things by having a prefix : e.g. appprefix_system1 appprefix_system2 ...
>>> 
>>> 
>>> Rahul Singh
>>> Chief Executive Officer | Business Platform Architect
>>> m: 202.905.2818 e: rahul.si...@anant.us  li: 
>>> http://linkedin.com/in/xingh 
>>> 
>>>  ca: http://calendly.com/xingh 
>>> 
>>> We create, support, and manage real-time global data & analytics platforms 
>>> for the modern enterprise.
>>> 
>>> Anant | https://anant.us 
>>> 
>>> 3 Washington Circle, Suite 301
>>> Washington, D.C. 20037
>>> 
>>> http://Cassandra.Link 
>>> 
>>>  : The best resources for Apache Cassandra
>>> 
>>> 
>>> On Tue, Apr 4, 2023 at 12:52 PM Jeff 

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

[Aleksey Yeshchenko]

Dig deeper :)

It’s existed since day one in both CQL2 and CQL3. 
https://github.com/apache/cassandra/blob/cassandra-1.0/src/java/org/apache/cassandra/cql/Cql.g#L526-L527

> On 10 Apr 2023, at 00:35, Patrick McFadin  wrote:
> 
> I was trying to remember when SCHEMA got added to the CQL parser. With a 
> quick 'git blame' I was taken back to this beast: 
> https://issues.apache.org/jira/browse/CASSANDRA-14825

Re: [VOTE] Release Apache Cassandra 3.11.15

[Aleksey Yeshchenko]

+1

> On 2 May 2023, at 07:37, Miklosovic, Stefan  
> wrote:
> 
> Proposing the test build of Cassandra 3.11.15 for release.
> 
> sha1: 6cdcf5e56a77cf40c251125d68856a614eccbc53
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.15-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1287/org/apache/cassandra/cassandra-all/3.11.15/
> 
> 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.15/
> 
> 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.15-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.15-tentative

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

[Aleksey Yeshchenko]

+1

> On 4 May 2023, at 17:46, Doug Rohrer  wrote:
> 
> Hello all,
> 
> I’d like to put CEP-28 to a vote.
> 
> Proposal:
> 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-28%3A+Reading+and+Writing+Cassandra+Data+with+Spark+Bulk+Analytics
> 
> Jira:
> https://issues.apache.org/jira/browse/CASSANDRA-16222
> 
> Draft implementation:
> 
> - Apache Cassandra Spark Analytics source code: 
> https://github.com/frankgh/cassandra-analytics
> - Changes required for Sidecar: 
> https://github.com/frankgh/cassandra-sidecar/tree/CEP-28-bulk-apis
> 
> Discussion:
> https://lists.apache.org/thread/lrww4d7cdxgtg8o3gt8b8foymzpvq7z3
> 
> The vote will be open for 72 hours. 
> A vote passes if there are at least three binding +1s and no binding vetoes. 
> 
> 
> Thanks,
> 
> Doug Rohrer
> 
> 

Re: [VOTE] Release Apache Cassandra 3.0.29

[Aleksey Yeshchenko]

+1

> On 8 May 2023, at 09:44, Miklosovic, Stefan  
> wrote:
> 
> Proposing the test build of Cassandra 3.0.29 for release.
> 
> sha1: 087cffce636b63c12e328994d52bdf8f4ccc9750
> Git: https://github.com/apache/cassandra/tree/3.0.29-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1288/org/apache/cassandra/cassandra-all/3.0.29/
> 
> 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.29/
> 
> 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/3.0.29-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/3.0.29-tentative/NEWS.txt

Re: [DISCUSS] The future of CREATE INDEX

[Aleksey Yeshchenko]

This.

I would also consider adding CREATE LEGACY INDEX syntax as an alias for today’s 
CREATE INDEX, the latter to be deprecated and (in very distant future) removed.

> On 12 May 2023, at 13:14, Benedict  wrote:
> 
> This creates huge headaches for everyone successfully using 2i today though, 
> and SAI *is not* guaranteed to perform as well or better - it has a very 
> different performance profile.
> 
> I think we should deprecate CREATE INDEX, and introduce new syntax CREATE 
> LOCAL INDEX to make clear that this is not a global index, and that this 
> should require the USING syntax to avoid this problem in future. 
> 
> We should report warnings to the client when CREATE INDEX is used, indicating 
> it is deprecated.

Re: Agrona vs fastutil and fastutil-concurrent-wrapper

[Aleksey Yeshchenko]

This ^

It’s an absolutely beautifully written library by Martin Thompson, my go-to for 
years if I’m ever asked for an example of a Java codebase to study. I have read 
it essentially entirely, and more than once, and it makes me feel a little 
happier but also inadequate every time I do.

It doesn’t have concurrent primitive collections though. We can use fastutils 
for that over stock CHM and boxing and friends if we deem it to be trustworthy 
enough.

P.S. FWIW we also have a long-keyed NBHM via jctools dependency - 
NonBlockingHashMapLong, if that’s all we need.

> On 25 May 2023, at 21:05, Benedict  wrote:
> 
> Nope, my awareness of Agrona predates Branimir’s proposal, as does others. 
> Aleksey intended to propose its inclusion beforehand also.
> 
> If all we’re getting is lock striping, do we really need a separate library?
> 
>> On 25 May 2023, at 19:33, Jonathan Ellis  wrote:
>> 
>> 
>> Let's not fall prey to status quo bias, nobody performed an exhaustive 
>> analysis of agrona in November.  If Branimir had proposed fastutils at the 
>> time that's what we'd be using today.
>> 
>> 
>> 
>> On Thu, May 25, 2023 at 10:50 AM Benedict > > wrote:
>>> Given they provide no data or explanation, and that benchmarking is hard, 
>>> I’m not inclined to give much weight to their analysis.
>>> 
>>> Agrona was favoured in large part due to the perceived quality of the 
>>> library. I’m not inclined to swap it out without proper evidence the 
>>> fastutils is both materially faster in a manner care about and of similar 
>>> quality.
>>> 
 On 25 May 2023, at 16:43, Jonathan Ellis >>> > wrote:
 
 
 Try it out and see, the only data point I have is that the company who has 
 spent more effort here than anyone else I could find likes fastutil better.
 
 On Thu, May 25, 2023 at 10:33 AM Dinesh Joshi >>> > wrote:
> > On May 25, 2023, at 6:14 AM, Jonathan Ellis  > > wrote:
> > 
> > Any objections to adding the concurrent wrapper and switching out 
> > agrona for fastutil?
> 
> How does fastutil compare to agrona in terms of memory profile and 
> runtime performance? How invasive would it be to switch?
 
 
 -- 
 Jonathan Ellis
 co-founder, http://www.datastax.com 
 @spyced
>> 
>> 
>> -- 
>> Jonathan Ellis
>> co-founder, http://www.datastax.com 
>> @spyced

Re: [VOTE] CEP-30 ANN Vector Search

[Aleksey Yeshchenko]

+1

> On 26 May 2023, at 07:19, Berenguer Blasi  wrote:
> 
> +1
> 
> On 26/5/23 6:07, guo Maxwell wrote:
>> +1
>> 
>> Dinesh Joshi mailto:djo...@apache.org>>于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 !

Re: [VOTE] CEP-8 Datastax Drivers Donation

[Aleksey Yeshchenko]

+1

> On 15 Jun 2023, at 15:19, Chris Lohfink  wrote:
> 
> +1
> 
> On Wed, Jun 14, 2023 at 9:05 PM Jon Haddad  > wrote:
>> +1
>> 
>> On 2023/06/13 14:14:35 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: [DISCUSSIONS] Replace ant eclipse-warnings with CheckerFramework

[Aleksey Yeshchenko]

Sounds like a clear improvement to me. Only once this check flagged a 
legitimate issue I missed, if I’m remembering correctly. All other instances 
have just been annoyances, forcing to add a redundant suppressed annotation. 

> On 15 Jun 2023, at 19:01, Ekaterina Dimitrova  wrote:
> 
> Hi everyone,
> Happy Thursday!
> Some time ago, Jacek raised the point that ant eclipse-warnings is generating 
> too many false positives and not really working as expected. (CASSANDRA-18239)
> Reminder: ant eclipse-warnings is a task we run with the goal to check 
> Cassandra code - static analysis to warn on unsafe use of Autocloseable 
> instances; checks against two related particular compiler options
> While trying to upgrade ECJ compiler that we use for this task 
> (CASSANDRA-18190) so we can switch the task from running it with JDK8 to 
> JDK11 in preparation for dropping JDK8, I hit the following issues:
> - the latest version of ECJ is throwing more than 300 Potential Resource Leak 
> warnings. I looked at 10-15, and they were all false positives. 
> - Even if we file a bug report to the Eclipse community, JDK11 is about to be 
> removed with the next version of the compiler
> 
> So I shared this information with Jacek. He came up with a different solution:
> It seems we already pull through Guava CheckerFramework with an MIT license, 
> which appears to be acceptable according to this link -  
> https://www.apache.org/legal/resolved.html#category-a
> He already has an initial integration with Cassandra which shows the 
> following:
> - CheckerFramework does not understand the @SuppressWarnings("resource") 
> (there is a different one to be used), so it is immediately visible how it 
> does not report all those false positives that eclipse-warnings does. On the 
> flip side, I got the feedback that what it has witnessed so far is something 
> we should investigate.
> - Also, there are additional annotations like @Owning that let you fix many 
> problems at once because the tool understands that the ownership of the 
> resources was passed to another entity; It also enables you to do something 
> impossible with eclipse-warnings - you can tell the tool that there is 
> another method that needs to be called to release the resources, like 
> release, free, disconnect, etc.
> - the tool works with JDK8, JDK11, JDK17, and JDK20, so we can backport it 
> even to older branches (while at the same time keeping eclipse-warnings there)
> - though it runs 8 minutes so, we should not run it with every test, some 
> reorganization around ant tasks will be covered as even for eclipse-warnings 
> it was weird to call it on every single test run locally by default
> 
> 
> If there are no concerns, we will continue replacing ant eclipse-warnings 
> with the CheckerFramework as part of CASSANDRA-18239 and CASSANDRA-18190 in 
> trunk.
> Best regards,
> Ekaterina

Re: Improved DeletionTime serialization to reduce disk size

[Aleksey Yeshchenko]

Distant future people will not be happy about this, I can already tell you now.

Sounds like a reasonable improvement to me however.

> On 23 Jun 2023, at 07:22, Berenguer Blasi  wrote:
> 
> Hi all,
> 
> DeletionTime.markedForDeleteAt is a long useconds since Unix Epoch. But I 
> noticed that with 7 bytes we can already encode ~2284 years. We can either 
> shed the 8th byte, for reduced IO and disk, or can encode some sentinel 
> values (such as LIVE) as flags there. That would mean reading and writing 1 
> byte instead of 12 (8 mfda long + 4 ldts int). Yes we already avoid 
> serializing DeletionTime (DT) in sstables at _row_ level entirely but not at 
> _partition_ level and it is also serialized at index, metadata, etc.
> 
> So here's a POC: https://github.com/bereng/cassandra/commits/ldtdeser-trunk 
> and some jmh (1) to evaluate the impact of the new alg (2). It's tested here 
> against a 70% and a 30% LIVE DTs  to see how we perform:
> 
>  [java] Benchmark (liveDTPcParam)  (sstableParam)  Mode  Cnt  Score   
> Error  Units
>  [java] DeletionTimeDeSerBench.testRawAlgReads 70PcLive  NC  
> avgt   15  0.331 ± 0.001  ns/op
>  [java] DeletionTimeDeSerBench.testRawAlgReads 70PcLive  OA  
> avgt   15  0.335 ± 0.004  ns/op
>  [java] DeletionTimeDeSerBench.testRawAlgReads 30PcLive  NC  
> avgt   15  0.334 ± 0.002  ns/op
>  [java] DeletionTimeDeSerBench.testRawAlgReads 30PcLive  OA  
> avgt   15  0.340 ± 0.008  ns/op
>  [java] DeletionTimeDeSerBench.testNewAlgWrites 70PcLive  NC  
> avgt   15  0.337 ± 0.006  ns/op
>  [java] DeletionTimeDeSerBench.testNewAlgWrites 70PcLive  OA  
> avgt   15  0.340 ± 0.004  ns/op
>  [java] DeletionTimeDeSerBench.testNewAlgWrites 30PcLive  NC  
> avgt   15  0.339 ± 0.004  ns/op
>  [java] DeletionTimeDeSerBench.testNewAlgWrites 30PcLive  OA  
> avgt   15  0.343 ± 0.016  ns/op
> 
> That was ByteBuffer backed to test the extra bit level operations impact. But 
> what would be the impact of an end to end test against disk?
> 
>  [java] Benchmark (diskRAMParam)  (liveDTPcParam)  (sstableParam)  Mode  
> Cnt ScoreError  Units
>  [java] DeletionTimeDeSerBench.testE2EDeSerializeDT RAM 70PcLive  
> NC  avgt   15   605236.515 ± 19929.058  ns/op
>  [java] DeletionTimeDeSerBench.testE2EDeSerializeDT RAM 70PcLive  
> OA  avgt   15   586477.039 ± 7384.632  ns/op
>  [java] DeletionTimeDeSerBench.testE2EDeSerializeDT RAM 30PcLive  
> NC  avgt   15   937580.311 ± 30669.647  ns/op
>  [java] DeletionTimeDeSerBench.testE2EDeSerializeDT RAM 30PcLive  
> OA  avgt   15   914097.770 ± 9865.070  ns/op
>  [java] DeletionTimeDeSerBench.testE2EDeSerializeDT   Disk 
> 70PcLive  NC  avgt   15  1314417.207 ± 37879.012  ns/op
>  [java] DeletionTimeDeSerBench.testE2EDeSerializeDT  Disk 
> 70PcLive  OA  avgt   15 805256.345 ±  15471.587  ns/op
>  [java] DeletionTimeDeSerBench.testE2EDeSerializeDT Disk 
> 30PcLive  NC  avgt   15 1583239.011 ±  50104.245  ns/op
>  [java] DeletionTimeDeSerBench.testE2EDeSerializeDTDisk 
> 30PcLive  OA  avgt   15 1439605.006 ±  64342.510  ns/op
>  [java] DeletionTimeDeSerBench.testE2ESerializeDT  RAM 
> 70PcLive  NC  avgt   15 295711.217 ±   5432.507  ns/op
>  [java] DeletionTimeDeSerBench.testE2ESerializeDTRAM 
> 70PcLive  OA  avgt   15 305282.827 ±   1906.841  ns/op
>  [java] DeletionTimeDeSerBench.testE2ESerializeDT  RAM 
> 30PcLive  NC  avgt   15   446029.899 ±   4038.938  ns/op
>  [java] DeletionTimeDeSerBench.testE2ESerializeDTRAM 30PcLive 
>  OA  avgt   15   479085.875 ± 10032.804  ns/op
>  [java] DeletionTimeDeSerBench.testE2ESerializeDT Disk 
> 70PcLive  NC  avgt   15  1789434.838 ± 206455.771  ns/op
>  [java] DeletionTimeDeSerBench.testE2ESerializeDT   Disk 
> 70PcLive  OA  avgt   15 589752.861 ±  31676.265  ns/op
>  [java] DeletionTimeDeSerBench.testE2ESerializeDTDisk 
> 30PcLive  NC  avgt   15 1754862.122 ± 164903.051  ns/op
>  [java] DeletionTimeDeSerBench.testE2ESerializeDT Disk 
> 30PcLive  OA  avgt   15  1252162.253 ± 121626.818  ns/o
> 
> We can see big improvements when backed with the disk and little impact from 
> the new alg.
> 
> Given we're already introducing a new sstable format (OA) in 5.0 I would like 
> to try to get this in before the freeze. The point being that sstables with 
> lots of small partitions would benefit from a smaller DT at partition level. 
> My tests show a 3%-4% size reduction on disk.
> 
> Before proceeding though I'd like to bounce the idea agains

Re: Changing the output of tooling between majors

[Aleksey Yeshchenko]

As Eric said, a major release is not a license to make externally visible 
breaking changes. We are too mature a project now.

I have OCD tendencies like many people here, but one must learn to live with 
aesthetically imperfect tool output. Internal changes are fine, external 
changes that are actual bug fixes are fine (but need to be undertaken with good 
care still).

> On 13 Jul 2023, at 23:36, Dinesh Joshi  wrote:
> 
> This adds maintenance overhead but is a potential alternative. I would only 
> flip the flag. I would prefer to make the default "legacy" output and 
> innovate behind a "--output-format=v2" flag. That way tools do not break or 
> have to change to pass in the new flag.
> 
> Ideally we should always version our output format - structured or not.
> 
> Dinesh
> 
>> On Jul 13, 2023, at 9:08 AM, German Eichberger via dev 
>>  wrote:
>> 
>> Let's take this discussion in a different direction: If we add a --legacy 
>> ​ argument where we are supporting an old version for those who 
>> need/want it but have the (breaking) changes on the default this feels like 
>> a compromise - and then we can deprecate the legacy format without impacting 
>> innovation. We can also flip this with requiring a flag for the changed 
>> format if we feel this is better.
>> 
>> This let's us innovate without breaking anyone. Thoughts?
>> 
>> Thanks,
>> German

Re: [DISCUSS] Vector type and empty value

[Aleksey Yeshchenko]

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 
>>> say I have a “blob” type and I write an empty byte… what does this mean?  
>>> What does it mean for "text" type?  The fact I get back a null in both 
>>> those cases was very confusing to me… I do feel that some types should 
>>> support empty, and the common code of empty == null I think is very brittle 
>>> (blob/text was not correct in different places due to this...)… so I am 
>>> cool with removing that relationship, but don’t think we should have a rule 
>>> blocking empty for all current / future types as it some times does make 
>>> sense.
>>> 
 empty vector (I presume) for the vector type?
>>> 
>>> Empty vectors (vector[0]) are blocked at the type level, the smallest 
>>> vector is vector[1]
>>> 
 as types that can never be null
>>> 
>>> One pro here is that “null” is cheaper (in some regards) than delete 
>>> (though we can never purge), but having 2 similar behaviors (write null, do 
>>> a delete) at the type level is a bit confusing… Right now I am allowed to 
>>> do the following (the below isn’t valid CQL, its a hybrid of CQL + Java 
>>> code…)
>>> 
>>> CREATE TABLE fluffykittens (pk int primary key, cuteness int);
>>> INSERT INTO fluffykittens (pk, cuteness) VALUES (0, new byte[0])
>>> 
>>> CREATE TABLE t

Re: [VOTE] Accept java-driver

[Aleksey Yeshchenko]

+1

> On 5 Oct 2023, at 10:35, Benedict  wrote:
> 
> Surely it needs to be shared with the foundation and the PMC so we can 
> verify? Or at least have ASF legal confirm they have received and are 
> satisfied with the tarball? It certainly can’t be kept private to DS, AFAICT.
> 
> Of course it shouldn’t be shared publicly but not sure how PMC can fulfil its 
> verification function here without it.
> 
>> On 5 Oct 2023, at 10:23, Mick Semb Wever  wrote:
>> 
>> 
>> 
>>.
>> 
>> On Tue, 3 Oct 2023 at 13:25, Josh McKenzie > > wrote:
 I see now this will likely be instead apache/cassandra-java-driver
>>> I was wondering about that. apache/java-driver seemed pretty broad. :)
>>> 
>>> From the linked page:
>>> Check that all active committers have a signed CLA on record. TODO – attach 
>>> list
>>> I've been part of these discussions and work so am familiar with the status 
>>> of it (as well as guidance and clearance from the foundation re: folks we 
>>> couldn't reach) - but might be worthwhile to link to the sheet or perhaps 
>>> instead provide a summary of the 49 java contributors, their CLA signing 
>>> status, attempts to reach out, etc for other PMC members that weren't 
>>> actively involved back when we were working through it.
>> 
>> 
>> 
>> We have a spreadsheet with this information, and the tarball of all the 
>> signed CLAs.
>> The tarball we should keep private to DS, but know that we have it for 
>> governance's sake.
>> 
>> I've attached the spreadsheet to the CEP confluence page.

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

[Aleksey Yeshchenko]

I’m not so sure that many folks will choose to go 4.0->5.0->5.1 path instead of 
just waiting longer for TCM+Accord to be in, and go 4.0->5.1 in one hop.

Nobody likes going through these upgrades. So I personally expect 5.0 to be a 
largely ghost release if we go this route, adopted by few, just a permanent 
burden on the merge path to trunk.

Not to say that there isn’t valuable stuff in 5.0 without TCM and Accord - 
there most certainly is - but with the expectation that 5.1 will follow up 
reasonably shortly after with all that *and* two highly anticipated features on 
top, I just don’t see the point. It will be another 2.2 release.


> On 23 Oct 2023, at 17:43, Josh McKenzie  wrote:
> 
> We discussed that at length in various other mailing threads Jeff - kind of 
> settled on "we're committing to cutting a major (semver MAJOR or MINOR) every 
> 12 months but want to remain flexible for exceptions when appropriate".
> 
> And then we discussed our timeline for 5.0 this year and settled on the 
> "let's try and get it out this calendar year so it's 12 months after 4.1, but 
> we'll grandfather in TCM and Accord past freeze date if they can make it by 
> October".
> 
> So that's the history for how we landed here.
> 
>> 2) Do we drop the support of 3.0 and 3.11 after 5.0.0 is out or after 5.1.0 
>> is?
> This is my understanding, yes. Deprecation and support drop is predicated on 
> the 5.0 release, not any specific features or anything.
> 
> On Mon, Oct 23, 2023, at 12:29 PM, Jeff Jirsa wrote:
>> 
>> 
>> On Mon, Oct 23, 2023 at 4:52 AM Mick Semb Wever > > wrote:
>> 
>> The TCM work (CEP-21) is in its review stage but being well past our cut-off 
>> date¹ for merging, and now jeopardising 5.0 GA efforts, I would like to 
>> propose the following.
>> 
>> 
>> 
>> I think this presumes that 5.0 GA is date driven instead of feature driven.
>> 
>> I'm sure there's a conversation elsewhere, but why isn't this date movable?

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Aleksey Yeshchenko]

-1 on cutting a beta1 in this state. An alpha2 would be acceptable now, but I’m 
not sure there is significant value to be had from it. Merge the fixes for 
outstanding issues listed above, then cut beta1.

With TCM and Accord pushed into 5.1, SAI is the headliner user-visible feature. 
It is what we want users to test. If we are to drive more people to test SAI, 
we should resolve the issues that we ourselves know of first. Respect our 
users’ time and effort - don’t make them bump into known bugs.

P.S. I don’t believe that ‘alpha' vs. ‘beta' really makes a significant 
difference to people’s willingness to try out the build. For most folks both 
feel too raw to play with, and most of the rest would be equally adventurous 
enough for an alpha *or* a beta. This is just my gut feeling vs. your gut 
feeling, in absence of hard data.

> On 28 Nov 2023, at 21:17, Mick Semb Wever  wrote:
> 
> 
> 
>> So then cutting an alpha2 is possible.
> 
> 
> Possible, but still leaves alpha1 as our mitigation plan and alpha2 as our 
> best plan.  Doesn't seem worth it IMHO.

Re: [VOTE] Release Harry 0.0.2

[Aleksey Yeshchenko]

+1

> On 29 Nov 2023, at 11:35, Sam Tunnicliffe  wrote:
> 
> +1
> 
>> On 29 Nov 2023, at 11:14, Alex Petrov  wrote:
>> 
>> Even though we would like to bring harry in-tree, this is not an immediate 
>> priority. Meanwhile, we need to unblock RPM builds for trunk, which means no 
>> custom jars. We will have at least one more Harry release with outstanding 
>> features to avoid any blocking. 
>> 
>> Proposing the test build of cassandra-harry 0.0.2 for release, for TCM 
>> purposes.
>> 
>> Repository:
>> https://gitbox.apache.org/repos/asf?p=cassandra-harry.git;a=shortlog;h=refs/tags/0.0.2
>> 
>> Candidate SHA:
>> https://github.com/apache/cassandra-harry/commit/37761ce599242a34b027baff520e1185b7a7c3af
>> tagged with 0.0.2
>> 
>> Artifacts:
>> https://repository.apache.org/content/repositories/orgapachecassandra-1320
>> 
>> Key signature: A4C465FEA0C552561A392A61E91335D77E3E87CB
>> 
>> Prominent changes:
>> 
>> [CASSANDRA-18768] Improvements / changes required for Transactional Metadata 
>> testing:
>>   * Add an ability to run sequential r/w for more deterministic 
>> results
>>   * Implement Network Topology Strategy
>>   * Add all pds iterator to ops selector
>>   * Make sure to log when detecting that a run starts against a 
>> dirty table
>>   * Fix a concurrency issue with reorder buffer
>>   * Add some safety wheels / debugging instruments
>>   * Add a pd selector symmetry test
>>   * Make it simpler to write and log
>>   * Rename sequential rw to write before read
>>   * Avoid starving writers by readers and vice versa
>>   * Add a minimal guide for debugging falsifications
>>   * Fix select peers query for local state checker
>>   * Add examples for programmatic configuration
>> 
>> [CASSANDRA-18318] Implement parsing schema provider
>> [CASSANDRA-18315] Trigger exception if we run out of partitions
>> [CASSANDRA-17603] Allow selecting subsets of columns and wilcard queries.
>> [CASSANDRA-17603] Open API for hand-crafting both mutation and read queries
>> [CASSANDRA-17603] Make it possible to run multiple Harry runners 
>> concurrently against the same keyspace
>> [CASSANDRA-17603] Implement concurrent quiescent checker
>> [CASSANDRA-17603] Pull in token util from Cassandra to avoid circular 
>> dependency
>> [CASSANDRA-17603] Pull in Cassandra concurrent utils until there is a common 
>> shared library
>> 
>> 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: [DISCUSS] Harry in-tree

[Aleksey Yeshchenko]

+1

> On 29 Nov 2023, at 07:23, Marcus Eriksson  wrote:
> 
> +1!
> 
> /Marcus
> 
> On Fri, Nov 24, 2023 at 04:43:36PM +0100, Alex Petrov wrote:
>> Hi everyone,
>> 
>> With TCM landed, there will be way more Harry tests in-tree: we are using it 
>> for many coordination tests, and there's now a simulator test that uses 
>> Harry. During development, Harry has allowed us to uncover and resolve 
>> numerous elusive edge cases.
>> 
>> I had conversations with several folks, and wanted to propose to move 
>> harry-core to Cassandra test tree. This will substantially 
>> simplify/streamline co-development of Cassandra and Harry. With a new 
>> HistoryBuilder API that has helped to find and trigger [1] [2] and [3], it 
>> will also be much more approachable.
>> 
>> Besides making it easier for everyone to develop new fuzz tests, it will 
>> also substantially lower the barrier to entry. Currently, debugging an issue 
>> found by Harry involves a cumbersome process of rebuilding and transferring 
>> jars between Cassandra and Harry, depending on which side you modify. This 
>> not only hampers efficiency but also deters broader adoption. By merging 
>> harry-core into the Cassandra test tree, we eliminate this barrier.
>> 
>> Thank you,
>> --Alex
>> 
>> [1] https://issues.apache.org/jira/browse/CASSANDRA-19011
>> [2] https://issues.apache.org/jira/browse/CASSANDRA-18993
>> [3] https://issues.apache.org/jira/browse/CASSANDRA-18932

Re: [DISCUSS] Stream Pipelines on hot paths

[Aleksey Yeshchenko]

Ban in all new non-test code seems like the most pragmatic approach to me as 
well.

> On 7 Jun 2024, at 06:32, Jordan West  wrote:
> 
> Similarly in the "don't use them in the main project but am ok with tests" 
> camp
> 
> On Thu, Jun 6, 2024 at 4:46 AM Štefan Miklošovič  > wrote:
>> I have created 
>> 
>> https://issues.apache.org/jira/browse/CASSANDRA-19673
>> 
>> to gather all your ideas about what to remove. If you stumble upon some code 
>> which is susceptible to rewriting, just put it there.
>> 
>> On Wed, Jun 5, 2024 at 6:35 PM > > wrote:
>>> I would like to vote for banning streams in all non-test code. It may not 
>>> be easy for new contributors to distinguish between hot path and non-hot 
>>> path. So would be great if we can simply block them in non-test code and 
>>> update codestyle to detect the usage.
>>> 
>>> 
 On Jun 4, 2024, at 6:26 PM, Josh McKenzie >>> > wrote:
 
 I'm in the "ban in non-test cases, allow in tests" camp. Can sometimes 
 make things more expressive and concise.
 
 On Mon, Jun 3, 2024, at 12:07 PM, Sam wrote:
> Added.
> 
> Here is the 'after' profile
> 
> 
> 
> On Sun, 2 Jun 2024 at 20:50, Mick Semb Wever  > wrote:
>  
> On profiling a 90% write workload I found 
> StorageProxy::updateCoordinatorWriteLatencyTableMetric to be a hot-path, 
> consuming between 15-20% of 
> ModificationStatement::executeWithoutCondition cycles.
> 
> https://github.com/apache/cassandra/pull/3344
> 
> 
> 
> Ouch.  Ok, I've no idea what constitutes an ok "slow path" now…
> 
> Sam, can you also share in the ticket the easy-cass-stress profile you 
> used please.
>>> 

Re: [DISCUSS] Stream Pipelines on hot paths

[Aleksey Yeshchenko]

It am okay with its use off hot paths in principle, and I’ve done it myself.

But as others have mentioned, it’s not obvious to every contributor what is and 
isn’t a hot path. Also, the codebase is a living, shifting thing: a cold path 
today can suddenly become hot tomorrow - it’s not uncommon.

Another benefit to this binary decision flow is that we can easily enforce it 
with our lint tooling just for non-test part of the codebase. It’s just easier 
to scale.

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

Re: [VOTE][IP CLEARANCE] GoCQL driver

[Aleksey Yeshchenko]

+1

> On 26 Jun 2024, at 07:38, Ekaterina Dimitrova  wrote:
> 
> +1
> 
> On Wed, 26 Jun 2024 at 6:14, Jon Haddad  > wrote:
>> +1.  
>> 
>> On Wed, Jun 26, 2024 at 1:50 AM J. D. Jordan > > wrote:
>>> +1 nb. Good to see this heavily used driver get continued development in 
>>> the project.
>>> 
>>> > On Jun 25, 2024, at 5:29 PM, Michael Shuler >> > > wrote:
>>> > 
>>> > +1
>>> > 
>>> > Kind regards,
>>> > Michael
>>> > 
>>> >> On 6/25/24 12:29, Mick Semb Wever wrote:
>>> >> Please vote on the acceptance of the GoCQL driver and its IP Clearance:
>>> >> https://incubator.apache.org/ip-clearance/cassandra-gocql-driver.html 
>>> >> 
>>> >> All consent from original authors of the donation, and tracking of 
>>> >> collected CLAs, is found in:
>>> >>  - https://github.com/gocql/gocql/issues/1751 
>>> >> 
>>> >>  - 
>>> >> https://cwiki.apache.org/confluence/pages/worddav/preview.action?fileName=GoCQL+ASF+CLA+collection.xlsx&pageId=225152485
>>> >>  
>>> >> 
>>> >> These do not require acknowledgement before thevote.
>>> >> The code is prepared for donation at https://github.com/gocql/gocql 
>>> >> 
>>> >> Once thisvotepasses we will request ASF Infra to move the gocql/gocql 
>>> >> as-is to apache/cassandra-gocql-driver  . The master branch and tags, 
>>> >> with all their history, will be kept.  Because consent and CLAs were not 
>>> >> received from all original authors the source files keep additional 
>>> >> reference to their earlier copyright authors and license.
>>> >> This will become part of the Drivers subproject, ref CEP-8: 
>>> >> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+DataStax+Drivers+Donation
>>> >>  
>>> >> 
>>> >> PMC members, please check carefully the IP Clearance requirements 
>>> >> beforevoting.
>>> >> Thevotewill be open for 72 hours (or longer).Votesby PMC members are 
>>> >> considered binding. Avotepasses if there are at least three binding +1s 
>>> >> and no -1's.
>>> >> regards,
>>> >> Mick

Re: [VOTE] Release Apache Cassandra 5.0-rc1

[Aleksey Yeshchenko]

Not voting on this, however, if we expect to fix something specific between an 
RC and GA, then we shouldn’t be starting a vote on RC. In that case it should 
be another beta.

> On 27 Jun 2024, at 18:30, Brandon Williams  wrote:
> 
> The last time paxos v2 blocked us in CASSANDRA-19617 which also
> affected 4.1, I didn't get a sense of strong usage from the community,
> so I agree that RC shouldn't be blocked but this can get fixed before
> GA.  +1 from me.
> 
> Kind Regards,
> Brandon
> 
> On Tue, Jun 25, 2024 at 11:11 PM Jon Haddad  wrote:
>> 
>> 5.0 is a massive milestone.  A huge thank you to everyone that's invested 
>> their time into the release.  I've done a lot of testing, benchmarking, and 
>> tire kicking and it's truly mind blowing how much has gone into 5.0 and how 
>> great it is for the community.
>> 
>> I am a bit concerned that CASSANDRA-19668, which I found in 4.1, will also 
>> affect 5.0.  This is a pretty serious bug, where using Paxos v2 + off heap 
>> memtables can cause a SIGSEV process crash.  I've seen this happen about a 
>> dozen times with a client over the last 3 months.  Since the new trie 
>> memtables rely on off heap, and both Trie memtables & Paxos V2 is so 
>> compelling (esp for multi-dc users), I think there's a good chance that 
>> we'll be making an already bad problem even worse, for folks that use LWT.
>> 
>> Unfortunately, until next week I'm unable to put any time into this; I'm on 
>> vacation with my family.  I wish I had been able to confirm and raise this 
>> issue as a 5.0 blocker sooner, but I've deliberately tried to keep work 
>> stuff out of my mind.   Since I'm not 100% sure if this affects 5.0, I'm not 
>> blocking the RC, but I don't feel comfortable putting a +1 on a release that 
>> I'm at least 80% certain contains a process-crashing bug.
>> 
>> I have a simple 4.1 patch in CASSANDRA-19668, but I haven't landed a commit 
>> in several years and I have zero recollection of the entire process of 
>> getting it in, nor have I spent any time writing unit or dtests in the C* 
>> repo.  I ran a test of 160MM LWTs over several hours with my 4.1 branch and 
>> didn't hit any issues, but my client ran for weeks without hitting it so 
>> it's hard to say if I've actually addressed the problem, as it's a rare race 
>> condition.  Fwiw, I don't need to be the one to handle CASSANDRA-19668, so 
>> if someone wants to address it before me, please feel free.  It will likely 
>> take me a lot longer to deal with than someone more involved with the 
>> process, and I'd want 2 sets of eyes on it anyways given what I already 
>> mentioned previously about committing and testing.
>> 
>> Jon
>> 
>> 
>> On Tue, Jun 25, 2024 at 2:53 PM Mick Semb Wever  wrote:
>>> 
>>> 
>>> 
>>> .
>>> 
 Proposing the test build of Cassandra 5.0-rc1 for release.
 
 sha1: b43f0b2e9f4cb5105764ef9cf4ece404a740539a
 Git: https://github.com/apache/cassandra/tree/5.0-rc1-tentative
 Maven Artifacts: 
 https://repository.apache.org/content/repositories/orgapachecassandra-1336/org/apache/cassandra/cassandra-all/5.0-rc1/
>>> 
>>> 
>>> 
>>> The three green CI runs for this are
>>> - 
>>> https://app.circleci.com/pipelines/github/driftx/cassandra?branch=5.0-rc1-2
>>> - 
>>> https://app.circleci.com/pipelines/github/driftx/cassandra?branch=5.0-rc1-3
>>> - 
>>> https://app.circleci.com/pipelines/github/driftx/cassandra?branch=5.0-rc1-4
>>> 
>>> 

Re: Which approach should we use for exposing metrics through Virtual tables?

[Aleksey Yeshchenko]

I don’t think it’s really necessary. Or at least I’m not seeing why having 
individual, specialised virtual tables is not sufficient.

Nor do I think that we should expose everything that nodetool does, so IMO we 
shouldn’t aim for that. Even if the goal were to eventually deprecate and 
remove JMX/nodetool, we could do that without providing a CQL equivalent for 
everything it did.

—
AY

On 22 June 2018 at 16:11:43, Chris Lohfink (clohf...@apple.com) wrote:

However it is kinda necessary at some level for this "generalized" metrics.

Re: Testing 4.0 Post-Freeze

[Aleksey Yeshchenko]

If we want to have a stable, usable 4.0.0 release out in the next 6-12 months, 
there needs to be a focused effort on getting it out - or else it’ll just never 
happen.

This is more of a call to action and announcement of intent than an attempt to 
enforce policy; we can and probably will branch off 4.0, and keep trunk 
technically active. But so long as there is a critical mass of active 
contributors who are on board with only/mostly working on stability, bug fixes, 
and validation - both as assignees and reviewers - we’ll have a de-facto freeze.

And I have a feeling that there is such a critical mass.

—
AY

On 3 July 2018 at 22:23:38, Jeff Jirsa (jji...@gmail.com) wrote:

I think there's value in the psychological commitment that if someone has  
time to contribute, their contributions should be focused on validating a  
release, not pushing future features.  


On Tue, Jul 3, 2018 at 1:03 PM, Jonathan Haddad  wrote:  

> I agree with Josh. I don’t see how changing the convention around trunk  
> will improve the process, seems like it’ll only introduce a handful of  
> rollback commits when people forget.  
>  
> Other than that, it all makes sense to me.  
>  
> I’ve been working on a workload centric stress tool on and off for a little  
> bit in an effort to create something that will help with wider adoption in  
> stress testing. It differs from the stress we ship by including fully  
> functional stress workloads as well as a validation process. The idea being  
> to be flexible enough to test both performance and correctness in LWT and  
> MVs as well as other arbitrary workloads.  
>  
> https://github.com/thelastpickle/tlp-stress  
>  
> Jon  
>  
>  
> On Tue, Jul 3, 2018 at 12:28 PM Josh McKenzie   
> wrote:  
>  
> > Why not just branch a 4.0-rel and bugfix there and merge up while still  
> > accepting new features or improvements on trunk?  
> >  
> > I don't think the potential extra engagement in testing will balance out  
> > the atrophy and discouraging contributions / community engagement we'd  
> get  
> > by deferring all improvements and new features in an open-ended way.  
> >  
> > On Tue, Jul 3, 2018 at 1:33 PM sankalp kohli   
> > wrote:  
> >  
> > > Hi cassandra-dev@,  
> > >  
> > > With the goal of making Cassandra's 4.0 the most stable major release  
> to  
> > > date, we would like all committers of the project to consider joining  
> us  
> > in  
> > > dedicating their time and attention to testing, running, and fixing  
> > issues  
> > > in 4.0 between the September freeze and the 4.0 beta release. This  
> would  
> > > result in a freeze of new feature development on trunk or branches  
> during  
> > > this period, instead focusing on writing, improving, and running tests  
> or  
> > > fixing and reviewing bugs or performance regressions found in 4.0 or  
> > > earlier.  
> > >  
> > > How would this work?  
> > >  
> > > We propose that between the September freeze date and beta, a new  
> branch  
> > > would not be created and trunk would only have bug fixes and  
> performance  
> > > improvements committed to it. At the same time we do not want to  
> > discourage  
> > > community contributions. Not all contributors can be expected to be  
> aware  
> > > of such a decision or may be new to the project. In cases where new  
> > > features are contributed during this time, the contributor can be  
> > informed  
> > > of the current status of the release process, be encouraged to  
> contribute  
> > > to testing or bug fixing, and have their feature reviewed after the  
> beta  
> > is  
> > > reached.  
> > >  
> > >  
> > > What happens when beta is reached?  
> > >  
> > > Ideally, contributors who have made significant contributions to the  
> > > release will stick around to continue testing between beta and final  
> > > release. Any additional folks who continue this focus would also be  
> > greatly  
> > > appreciated.  
> > >  
> > > What about before the freeze?  
> > >  
> > > Testing new features is of course important. This isn't meant to  
> > discourage  
> > > development – only to enable us to focus on testing and hardening 4.0  
> to  
> > > deliver Cassandra's most stable major release. We would like to see  
> > > adoption of 4.0 happen much more quickly than its predecessor.  
> > >  
> > > Thanks for considering this proposal,  
> > > Sankalp Kohli  
> >  
> --  
> Jon Haddad  
> http://www.rustyrazorblade.com  
> twitter: rustyrazorblade  
>  

Re: Testing 4.0 Post-Freeze

[Aleksey Yeshchenko]

For what it’s worth, I’m fine with both formal branching-level freeze and 
informal ‘let people commit to trunk if they can find a reviewer’ one and will 
support either.

So long as either/both are communicated to the contributors, the only 
difference is in where new feature work gets accumulated: will stay a bit 
longer in personal branches in the latter way.

—
AY

On 4 July 2018 at 01:30:40, sankalp kohli (kohlisank...@gmail.com) wrote:

Having an explicit way to tell the community that we all will work on  
testing is better than writing a patch which will sit without review for  
months. I think not having your patch reviewed for months is more  
discouraging than following the community and helping with stability of  
4.0.  



On Tue, Jul 3, 2018 at 3:02 PM Josh McKenzie  wrote:  

> >  
> > We propose that between the September freeze date and beta, a new branch  
> > would not be created and trunk would only have bug fixes and performance  
> > improvements committed to it.  
>  
>  
> This is more of a call to action and announcement of intent than an attempt  
> > to  
> > enforce policy; we can and probably will branch off 4.0, and keep trunk  
> > technically active.  
>  
> These are two very different statements. :) Which is it?  
>  
> On Tue, Jul 3, 2018 at 5:57 PM Aleksey Yeshchenko   
> wrote:  
>  
> > If we want to have a stable, usable 4.0.0 release out in the next 6-12  
> > months, there needs to be a focused effort on getting it out - or else  
> > it’ll just never happen.  
> >  
> > This is more of a call to action and announcement of intent than an  
> > attempt to enforce policy; we can and probably will branch off 4.0, and  
> > keep trunk technically active. But so long as there is a critical mass of  
> > active contributors who are on board with only/mostly working on  
> stability,  
> > bug fixes, and validation - both as assignees and reviewers - we’ll have  
> a  
> > de-facto freeze.  
> >  
> > And I have a feeling that there is such a critical mass.  
> >  
> > —  
> > AY  
> >  
> > On 3 July 2018 at 22:23:38, Jeff Jirsa (jji...@gmail.com) wrote:  
> >  
> > I think there's value in the psychological commitment that if someone has  
> > time to contribute, their contributions should be focused on validating a  
> > release, not pushing future features.  
> >  
> >  
> > On Tue, Jul 3, 2018 at 1:03 PM, Jonathan Haddad   
> > wrote:  
> >  
> > > I agree with Josh. I don’t see how changing the convention around trunk  
> > > will improve the process, seems like it’ll only introduce a handful of  
> > > rollback commits when people forget.  
> > >  
> > > Other than that, it all makes sense to me.  
> > >  
> > > I’ve been working on a workload centric stress tool on and off for a  
> > little  
> > > bit in an effort to create something that will help with wider adoption  
> > in  
> > > stress testing. It differs from the stress we ship by including fully  
> > > functional stress workloads as well as a validation process. The idea  
> > being  
> > > to be flexible enough to test both performance and correctness in LWT  
> > and  
> > > MVs as well as other arbitrary workloads.  
> > >  
> > >  
> >  
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_thelastpickle_tlp-2Dstress&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&m=l_G2ByhfCyu3k9TzNVqiagdVQ8vOMJqHZvDq_JKvbiQ&s=f8gf_JCP6JRQIRkL_1R_zJOS_6gdAAsLleDr2PZHppE&e=
>   
> >  
> > >  
> > > Jon  
> > >  
> > >  
> > > On Tue, Jul 3, 2018 at 12:28 PM Josh McKenzie   
> > > wrote:  
> > >  
> > > > Why not just branch a 4.0-rel and bugfix there and merge up while  
> > still  
> > > > accepting new features or improvements on trunk?  
> > > >  
> > > > I don't think the potential extra engagement in testing will balance  
> > out  
> > > > the atrophy and discouraging contributions / community engagement  
> > we'd  
> > > get  
> > > > by deferring all improvements and new features in an open-ended way.  
> > > >  
> > > > On Tue, Jul 3, 2018 at 1:33 PM sankalp kohli  >  
> >  
> > > > wrote:  
> > > >  
> > > > > Hi cassandra-dev@,  
> > > > >  
> > > > > With the goal of making Cassandra's 4.0 the most stable major  
> > release  
> > > to  
> > >

Re: Testing 4.0 Post-Freeze

[Aleksey Yeshchenko]

+1 from me too.

—
AY

On 10 July 2018 at 04:17:26, Mick Semb Wever (m...@apache.org) wrote:


> We have done all this for previous releases and we know it has not worked  
> well. So how giving it one more try is going to help here. Can someone  
> outline what will change for 4.0 which will make it more successful?  


I (again) agree with you Sankalp :-)  

Why not try something new?  
It's easier to discuss these things more genuinely after trying it out.  

One of the differences in the branching approaches: to feature-freeze on a 4.0 
branch or on trunk; is who it is that has to then merge and work with multiple 
branches.  

Where that small but additional effort is placed I think becomes a signal to 
what the community values most: new features or stability.  

I think most folk would vote for stability, so why not give this approach a go 
and to learn from it.  
It also creates an incentive to make the feature-freeze period as short as 
possible, moving us towards an eventual goal of not needing to feature-freeze 
at all.  

regards,  
Mick  

-  
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org  
For additional commands, e-mail: dev-h...@cassandra.apache.org  

Re: [VOTE] Branching Change for 4.0 Freeze

[Aleksey Yeshchenko]

+1

—
AY

On 11 July 2018 at 22:47:03, sankalp kohli (kohlisank...@gmail.com) wrote:

Hi,  
As discussed in the thread[1], we are proposing that we will not branch  
on 1st September but will only allow following merges into trunk.  

a. Bug and Perf fixes to 4.0.  
b. Critical bugs in any version of C*.  
c. Testing changes to help test 4.0  

If someone has a change which does not fall under these three, we can  
always discuss it and have an exception.  

Vote will be open for 72 hours.  

Thanks,  
Sankalp  

[1]  
https://lists.apache.org/thread.html/494c3ced9e83ceeb53fa127e44eec6e2588a01b769896b25867fd59f@%3Cdev.cassandra.apache.org%3E
  

Re: GitHub PR ticket spam

[Aleksey Yeshchenko]

Nice indeed. I assume it also doesn’t spam commits@ when done this way, in 
which case double +1 from me.

—
AY

On 6 August 2018 at 17:18:36, Jeremiah D Jordan (jeremiah.jor...@gmail.com) 
wrote:

Oh nice. I like the idea of keeping it but moving it to the worklog tab. +1 on 
that from me.  

> On Aug 6, 2018, at 5:34 AM, Stefan Podkowinski  wrote:  
>  
> +1 for worklog option  
>  
> Here's an example ticket from Arrow, where they seem to be using the  
> same approach:  
> https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_ARROW-2D2583&d=DwICaQ&c=adz96Xi0w1RHqtPMowiL2g&r=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g&m=wYZwHSze6YITTXgzOrEvfr_onojahtjeJRzGAt8ByzM&s=KWt0xsOv9ESaieg432edGvPhktGkWHxVuLAdNyORiYY&e=
>  
> 
>   
>  
>  
> On 05.08.2018 09:56, Mick Semb Wever wrote:  
>>> I find this a bit annoying while subscribed to commits@,  
>>> especially since we created pr@ for these kind of messages. Also I don't  
>>> really see any value in mirroring all github comments to the ticket.  
>>  
>>  
>> I agree with you Stefan. It makes the jira tickets quite painful to read. 
>> And I tend to make comments on the commits rather than the PRs so to avoid 
>> spamming back to the jira ticket.  
>>  
>> But the linking to the PR is invaluable. And I can see Ariel's point about a 
>> chronological historical archive.  
>>  
>>  
>>> Ponies would be for this to be mirrored to a tab  
>>> separate from comments in JIRA.  
>>  
>>  
>> Ariel, that would be the the "worklog" option.  
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__reference.apache.org_pmc_github&d=DwICaQ&c=adz96Xi0w1RHqtPMowiL2g&r=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g&m=wYZwHSze6YITTXgzOrEvfr_onojahtjeJRzGAt8ByzM&s=1lWQawAO9fITzakpnmdzERuCbZs6IGQsUH_EEIMCMqs&e=
>>  
>> 
>>   
>>  
>> If this works for you, and others, I can open a INFRA to switch to worklog.  
>> wdyt?  
>>  
>>  
>> Mick.  
>>  
>> -  
>> 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: Side Car New Repo vs not

[Aleksey Yeshchenko]

FWIW I’m strongly -1 on in-tree approach, and would much prefer a separate 
repo, dtest-style.

—
AY

On 21 August 2018 at 16:36:02, Jeremiah D Jordan (jeremiah.jor...@gmail.com) 
wrote:

I think the following is a very big plus of it being in tree:  
>> * Faster iteration speed in general. For example when we need to add a  
>> new  
>> JMX endpoint that the sidecar needs, or change something from JMX to a  
>> virtual table (e.g. for repair, or monitoring) we can do all changes  
>> including tests as one commit within the main repository and don't have  
>> to  
>> commit to main repo, sidecar repo,  

I also don’t see a reason why the sidecar being in tree means it would not work 
in a mixed version cluster. The nodes themselves must work in a mixed version 
cluster during a rolling upgrade, I would expect any management side car to 
operate in the same manor, in tree or not.  

This tool will be pretty tightly coupled with the server, and as someone with 
experience developing such tightly coupled tools, it is *much* easier to make 
sure you don’t accidentally break them if they are in tree. How many times has 
someone updated some JMX interface, updated nodetool, and then moved on? 
Breaking all the external tools not in tree, without realizing it. The above 
point about being able to modify interfaces and the side car in the same commit 
is huge in terms of making sure someone doesn’t inadvertently break the side 
car while fixing something else.  

-Jeremiah  


> On Aug 21, 2018, at 10:28 AM, Jonathan Haddad  wrote:  
>  
> Strongly agree with Blake. In my mind supporting multiple versions is  
> mandatory. As I've stated before, we already do it with Reaper, I'd  
> consider it a major misstep if we couldn't support multiple with the  
> project - provided admin tool. It's the same reason dtests are separate -  
> they work with multiple versions.  
>  
> The number of repos does not affect distribution - if we want to ship  
> Cassandra with the admin / repair tool (we should, imo), that can be part  
> of the build process.  
>  
>  
>  
>  
> On Mon, Aug 20, 2018 at 9:21 PM Blake Eggleston   
> wrote:  
>  
>> If the sidecar is going to be on a different release cadence, or support  
>> interacting with mixed mode clusters, then it should definitely be in a  
>> separate repo. I don’t even know how branching and merging would work in a  
>> repo that supports 2 separate release targets and/or mixed mode  
>> compatibility, but I’m pretty sure it would be a mess.  
>>  
>> As a cluster management tool, mixed mode is probably going to be a goal at  
>> some point. As a new project, it will benefit from not being tied to the C*  
>> release cycle (which would probably delay any sidecar release until  
>> whenever 4.1 is cut).  
>>  
>>  
>> On August 20, 2018 at 3:22:54 PM, Joseph Lynch (joe.e.ly...@gmail.com)  
>> wrote:  
>>  
>> I think that the pros of incubating the sidecar in tree as a tool first  
>> outweigh the alternatives at this point of time. Rough tradeoffs that I  
>> see:  
>>  
>> Unique pros of in tree sidecar:  
>> * Faster iteration speed in general. For example when we need to add a  
>> new  
>> JMX endpoint that the sidecar needs, or change something from JMX to a  
>> virtual table (e.g. for repair, or monitoring) we can do all changes  
>> including tests as one commit within the main repository and don't have  
>> to  
>> commit to main repo, sidecar repo, and dtest repo (juggling version  
>> compatibility along the way).  
>> * We can in the future more easily move serious background functionality  
>> like compaction or repair itself (not repair scheduling, actual  
>> repairing)  
>> into the sidecar with a single atomic commit, we don't have to do two  
>> phase  
>> commits where we add some IPC mechanism to allow us to support it in  
>> both,  
>> then turn it on in the sidecar, then turn it off in the server, etc...  
>> * I think that the verification is much easier (sounds like Jonathan  
>> disagreed on the other thread, I could certainly be wrong), and we don't  
>> have to worry about testing matrices to assure that the sidecar works  
>> with  
>> various versions as the version of the sidecar that is released with that  
>> version of Cassandra is the only one we have to certify works. If people  
>> want to pull in new versions or maintain backports they can do that at  
>> their discretion/testing.  
>> * We can iterate and prove value before committing to a choice. Since it  
>> will be a separate artifact from the start we can always move the  
>> artifact  
>> to a separate repo later (but moving the other way is harder).  
>> * Users will get the sidecar "for free" when they install the daemon,  
>> they  
>> don't need to take affirmative action to e.g. be able to restart their  
>> cluster, run repair, or back their data up; it just comes out of the box  
>> for free.  
>>  
>> Unique pros of a separate repository sidecar:  
>> * We can use a more

Re: Side Car New Repo vs not

[Aleksey Yeshchenko]

Sure, allow me to elaborate - at least a little bit. But before I do, just let 
me note that this wasn’t a veto -1, just a shorthand for “I don’t like this 
option”.

It would be nice to have sidecar and C* version and release cycles fully 
decoupled. I know it *can* be done when in-tree, but the way we vote on 
releases with tags off current branches would have to change somehow. Probably 
painfully. It would be nice to be able to easily enforce freezes, like the 
upcoming one, on the whole C* repo, while allowing feature development on the 
sidecar. It would be nice to not have sidecar commits in emails from commits@ 
mailing list. It would be nice to not have C* CI trigger necessarily on sidecar 
commits. Groups of people working on the two repos will mostly be different 
too, so what’s the point in sharing the repo?

Having an extra repo with its own set of branches is cheap and easy - we 
already do that with dtests. I like cleanly separated things when coupling is 
avoidable. As such I would prefer the sidecar to live in a separate new repo, 
while still being part of the C* project.

—
AY

On 21 August 2018 at 17:06:39, sankalp kohli (kohlisank...@gmail.com) wrote:

Hi Aleksey,  
Can you please elaborate on the reasons for your -1? This  
way we can make progress towards any one approach.  
Thanks,  
Sankalp  

On Tue, Aug 21, 2018 at 8:39 AM Aleksey Yeshchenko   
wrote:  

> FWIW I’m strongly -1 on in-tree approach, and would much prefer a separate  
> repo, dtest-style.  
>  
> —  
> AY  
>  
> On 21 August 2018 at 16:36:02, Jeremiah D Jordan (  
> jeremiah.jor...@gmail.com) wrote:  
>  
> I think the following is a very big plus of it being in tree:  
> >> * Faster iteration speed in general. For example when we need to add a  
> >> new  
> >> JMX endpoint that the sidecar needs, or change something from JMX to a  
> >> virtual table (e.g. for repair, or monitoring) we can do all changes  
> >> including tests as one commit within the main repository and don't  
> have  
> >> to  
> >> commit to main repo, sidecar repo,  
>  
> I also don’t see a reason why the sidecar being in tree means it would not  
> work in a mixed version cluster. The nodes themselves must work in a mixed  
> version cluster during a rolling upgrade, I would expect any management  
> side car to operate in the same manor, in tree or not.  
>  
> This tool will be pretty tightly coupled with the server, and as someone  
> with experience developing such tightly coupled tools, it is *much* easier  
> to make sure you don’t accidentally break them if they are in tree. How  
> many times has someone updated some JMX interface, updated nodetool, and  
> then moved on? Breaking all the external tools not in tree, without  
> realizing it. The above point about being able to modify interfaces and the  
> side car in the same commit is huge in terms of making sure someone doesn’t  
> inadvertently break the side car while fixing something else.  
>  
> -Jeremiah  
>  
>  
> > On Aug 21, 2018, at 10:28 AM, Jonathan Haddad   
> wrote:  
> >  
> > Strongly agree with Blake. In my mind supporting multiple versions is  
> > mandatory. As I've stated before, we already do it with Reaper, I'd  
> > consider it a major misstep if we couldn't support multiple with the  
> > project - provided admin tool. It's the same reason dtests are separate  
> -  
> > they work with multiple versions.  
> >  
> > The number of repos does not affect distribution - if we want to ship  
> > Cassandra with the admin / repair tool (we should, imo), that can be  
> part  
> > of the build process.  
> >  
> >  
> >  
> >  
> > On Mon, Aug 20, 2018 at 9:21 PM Blake Eggleston   
> > wrote:  
> >  
> >> If the sidecar is going to be on a different release cadence, or  
> support  
> >> interacting with mixed mode clusters, then it should definitely be in  
> a  
> >> separate repo. I don’t even know how branching and merging would work  
> in a  
> >> repo that supports 2 separate release targets and/or mixed mode  
> >> compatibility, but I’m pretty sure it would be a mess.  
> >>  
> >> As a cluster management tool, mixed mode is probably going to be a goal  
> at  
> >> some point. As a new project, it will benefit from not being tied to  
> the C*  
> >> release cycle (which would probably delay any sidecar release until  
> >> whenever 4.1 is cut).  
> >>  
> >>  
> >> On August 20, 2018 at 3:22:54 PM, Joseph Lynch (joe.e.ly...@gmail.com)  
>  
> >> wrote:  
> >>  
> >> I think that the pros of incubating

Re: Moving tickets out of 4.0 post freeze

[Aleksey Yeshchenko]

We could continue as 4.0.x, 5.0.x, 6.0.x, 7.0.x, 8.0.x, 9.0.x, with minor 
forever fixed to 0.

But I’m also struggling with how to justify the existence of that unused digit. 
We have never really done semantic versioning, we’ve arbitrarily flipped the 
major whenever we felt like “it was the right time” and/or for marketing 
reasons. Might as well drop the charade, and C*4 seems as good time as any to 
do that.

Perhaps we should discuss this in a separate thread, maybe closer to 4.0 
release time, so that it doesn’t distract us from more important current issues.

> On 24 Sep 2018, at 17:55, Jeremiah D Jordan  wrote:
> 
> So as to not confuse people, even if we never put out a 4.1, I think we 
> should keep it 4.0.x, in line with 2.2.x, 3.0.x, 3.11.x.  And yes our  Major>.. versioning of the past never followed semver.
> 
> -Jeremiah
> 
>> On Sep 24, 2018, at 11:45 AM, Benedict Elliott Smith  
>> wrote:
>> 
>> I’d like to propose we don’t do Semver.  Back when we did this before, there 
>> wasn’t any clear distinction between a major and a minor release.  They were 
>> both infrequent, both big, and were treated as majors for EOL'ing support 
>> for older releases.  This must surely have been confusing for users, and I’m 
>> not sure what we got from it?
>> 
>> Why don’t we keep it simple, and just have major.patch?  So we would release 
>> simply ‘4’ now, and the next feature release would be ‘5'.
>> 
>> 
>> 
>> 
>>> On 24 Sep 2018, at 17:34, Michael Shuler  wrote:
>>> 
>>> On 9/24/18 7:09 AM, Joshua McKenzie wrote:
 I propose we move all new features and improvements to 4.0.x to keep the
 surface area of change for the major stable.
>>> 
>>> It occurs to me that we should probably update the version in trunk to
>>> 4.0.0, if we're following semantic versions. I suppose this also means
>>> all the tickets for 4.x should be updated to 4.0.x, 4.0 to 4.0.0, etc.
>>> 
>>> -- 
>>> Michael
>>> 
>>> -
>>> 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: Using Cassandra as local db without cluster

[Aleksey Yeshchenko]

I agree with Jeff here.

Furthermore, Cassandra should generally be your solution of last resort - if 
nothing else works out.

In your case I’d try sqlite or leveldb (or rocksdb).

> On 18 Oct 2018, at 11:46, Jeff Jirsa  wrote:
> 
> I can’t think of a situation where I’d choose Cassandra as a database in a 
> single-host use case (if you’re sure it’ll never be more than one machine).
> 
> -- 
> Jeff Jirsa
> 
> 
>> On Oct 18, 2018, at 12:31 PM, Abdelkrim Fitouri  wrote:
>> 
>> Hello,
>> 
>> I am wondering if using cassandra as one local database without the cluster
>> capabilities has a sens, (i cannot do multi node cluster due to a technical
>> constraint)
>> 
>> I have an application with a purpose to store a dynamic number of colones
>> on each rows (thing that i cannot do with classical relational database),
>> and i don't want to use documents based nosql database to avoid using Json
>> marshal and unmarshal treatments...
>> 
>> Does cassandra with only one node and with a well designer model based on
>> queries and partition keys can lead to best performance than postgresql ?
>> 
>> Does cassandra have some limitation about the size of data ? about the
>> number of partition on a node ?
>> 
>> Thanks for any details or help.
>> 
>> --
>> 
>> Best Regards.
> 
> -
> 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: JIRA Workflow Proposals

[Aleksey Yeshchenko]

1. C, D, A, B, E
2. B, C, A
3. A
4. Meh

> On 11 Dec 2018, at 16:28, Benedict Elliott Smith  wrote:
> 
> Just to re-summarise the questions for people:
> 
> 1. (A) Only contributors may edit or transition issues; (B) Only contributors 
> may transition issues; (C) Only Jira-users may transition issues*; (D) 
> (C)+Remove contributor role entirely; (E) Leave permission as they are today
> 2. Priority on Bug issue type: (A) remove it; (B) auto-populate it; (C) leave 
> it.  Please rank.
> 3. Top priority: (A) Urgent; (B) Blocker.  See here for my explanation of why 
> I chose Urgent 
>   
> >.
> 4. Priority keep ‘Wish’ (to replace issue type): +1/-1
> 
> With my answers (again, sorry):
> 
> 1: A B C D E
> 2: B C A
> 3: A
> 4: +0.5
> 
>> On 11 Dec 2018, at 16:25, Benedict Elliott Smith  wrote:
>> 
>> It looks like we have a multiplicity of views on permissions, so perhaps we 
>> should complicate this particular vote with all of the possible options that 
>> have been raised so far (including one off-list).  Sorry everyone for the 
>> confusion.
>> 
>> (A) Only contributors may edit or transition issues; (B) Only contributors 
>> may transition issues; (C) Only Jira-users may transition issues*; (D) 
>> (C)+Remove contributor role entirely; (E) Leave permission as they are today
>> 
>> * Today apparently ‘Anyone’ can perform this operation
>> 
>> A ranked vote, please.  This makes my votes:
>> 
>> 1: A B C D E
>> 2: B C A
>> 3: A
>> 4: +0.5
>> 
>> 
>>> On 11 Dec 2018, at 05:51, Dinesh Joshi  
>>> wrote:
>>> 
>>> I agree with this. I generally am on the side of freedom and 
>>> responsibility. Limiting edits to certain fields turns people off. 
>>> Something I want to very much avoid if we can. 
>>> 
>>> Dinesh
>>> 
 On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan  
 wrote:
 
 On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
  wrote:
> 
>> On 10 Dec 2018, at 16:21, Ariel Weisberg  wrote:
>> 
>> Hi,
>> 
>> RE #1, does this mean if you submit a ticket and you are not a 
>> contributor you can't modify any of the fields including description or 
>> adding/removing attachments?
> 
> Attachment operations have their own permissions, like comments.  
> Description would be prohibited though.  I don’t see this as a major 
> problem, really; it is generally much more useful to add comments.  If we 
> particularly want to make a subset of fields editable there is a 
> workaround, though I’m not sure anybody would have the patience to 
> implement it:  
> https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
>  
> 
> 
 
 That would be disappointing. Descriptions with broken or no formatting
 aren't rare (say, command output without code formatting). And every
 now and then the description might need to be updated. For example, in
 https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to the
 paper had rotted, but I managed to find a new one, so I could edit it
 in. If such a change had to be posted as a comment, it might easily
 get lost in some of the more active issues.
 
 -
 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: [VOTE] Change Jira Workflow

[Aleksey Yeshchenko]

Sure, +1

> On 18 Dec 2018, at 09:42, Joseph Lynch  wrote:
> 
> +1 non-binding
> 
> On Tue, Dec 18, 2018 at 1:15 AM Sylvain Lebresne  wrote:
> 
>> +1
>> --
>> Sylvain
>> 
>> 
>> On Tue, Dec 18, 2018 at 9:34 AM Oleksandr Petrov <
>> oleksandr.pet...@gmail.com>
>> wrote:
>> 
>>> +1
>>> 
>>> On Mon, Dec 17, 2018 at 7:12 PM Nate McCall  wrote:
 
 On Tue, Dec 18, 2018 at 4:19 AM Benedict Elliott Smith
  wrote:
> 
> I propose these changes <
>>> 
>> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
>>> *
>>> to the Jira Workflow for the project.  The vote will be open for 72
>> hours**.
> 
 
 
 +1
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
 For additional commands, e-mail: dev-h...@cassandra.apache.org
 
>>> 
>>> 
>>> --
>>> alex p
>>> 
>>> -
>>> 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.4

[Aleksey Yeshchenko]

+1

> On 3 Feb 2019, at 00:31, Michael Shuler  wrote:
> 
> I propose the following artifacts for release as 3.11.4.
> 
> sha1: fd47391aae13bcf4ee995abcde1b0e180372d193
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.4-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1170/org/apache/cassandra/apache-cassandra/3.11.4/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1170/
> 
> The Debian and RPM packages are available here:
> http://people.apache.org/~mshuler
> 
> The vote will be open for 72 hours (longer if needed).
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.4-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.4-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 3.0.18

[Aleksey Yeshchenko]

+1

> On 4 Feb 2019, at 00:39, Joseph Lynch  wrote:
> 
> 3.0.18-tentative unit and dtest run:
> https://circleci.com/gh/jolynch/cassandra/tree/3.0.18-tentative
> 
> unit tests: 0 failures
> dtests: 1 failure
> * test_closing_connections - thrift_hsha_test.TestThriftHSHA (
> https://issues.apache.org/jira/browse/CASSANDRA-14595)
> 
> +1 non binding
> 
> -Joey
> 
> On Sat, Feb 2, 2019 at 4:32 PM Michael Shuler 
> wrote:
> 
>> I propose the following artifacts for release as 3.0.18.
>> 
>> sha1: edd52cef50a6242609a20d0d84c8eb74c580035e
>> Git:
>> 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.18-tentative
>> Artifacts:
>> 
>> https://repository.apache.org/content/repositories/orgapachecassandra-1171/org/apache/cassandra/apache-cassandra/3.0.18/
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachecassandra-1171/
>> 
>> The Debian and RPM packages are available here:
>> http://people.apache.org/~mshuler
>> 
>> The vote will be open for 72 hours (longer if needed).
>> 
>> [1]: CHANGES.txt:
>> 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.18-tentative
>> [2]: NEWS.txt:
>> 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.18-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 2.2.14

[Aleksey Yeshchenko]

+1

> On 3 Feb 2019, at 00:32, Michael Shuler  wrote:
> 
> I propose the following artifacts for release as 2.2.14.
> 
> sha1: af91658353ba601fc8cd08627e8d36bac62e936a
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.14-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1172/org/apache/cassandra/apache-cassandra/2.2.14/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1172/
> 
> The Debian and RPM packages are available here:
> http://people.apache.org/~mshuler
> 
> The vote will be open for 72 hours (longer if needed).
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.14-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.14-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 2.1.21

[Aleksey Yeshchenko]

Not sure we need another 2.1 release, this one included, but sure, +1

So long as the branch itself stays kinda open and most critical issues can have 
at least fixes for them committed, the interested parties can then keep 
building the artefacts manually.

Once 4.0 is out we can freeze the branch for good as well.

> On 3 Feb 2019, at 00:32, Michael Shuler  wrote:
> 
> *EOL* release for the 2.1 series. There will be no new releases from the
> 'cassandra-2.1' branch after this release.
> 
> 
> 
> I propose the following artifacts for release as 2.1.21.
> 
> sha1: 9bb75358dfdf1b9824f9a454e70ee2c02bc64a45
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.21-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1173/org/apache/cassandra/apache-cassandra/2.1.21/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1173/
> 
> The Debian and RPM packages are available here:
> http://people.apache.org/~mshuler
> 
> The vote will be open for 72 hours (longer if needed).
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.1.21-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.1.21-tentative
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Jira: Author Field

[Aleksey Yeshchenko]

Some of it is just for clear attribution.

Occasionally, you do get an extensive review that borders on 
authoring/coauthoring.

Sometimes you get a large body of work co-created by several people in author 
capacity.

Having a multi-user Authors field, in addition to the multi-user Reviewers 
field that we already have, allows to more accurately reflect on the ticket who 
contributed in what capacity.

> On 8 Apr 2019, at 14:01, Joshua McKenzie  wrote:
> 
> What problem are we trying to solve w/this proposed change?
> 
> Is the thinking for live querying of things in progress, or is the thinking
> for after-the-fact research to determine who wrote a thing to reach out to
> them for context? If the latter, does a change in JIRA metadata give us
> more context than good git commit message hygiene (i.e. list all authors on
> commit msg)?
> 
> fwiw, no religion on the topic here. Just curious.
> 
> 
> On Mon, Apr 8, 2019 at 8:55 AM Benedict Elliott Smith 
> wrote:
> 
>> A couple of people have recently raised the possibility of an Author field
>> in JIRA, that permits multiple authors (much like we now support multiple
>> reviewers).
>> 
>> Unfortunately this can never be quite as clean as Reviewers, as Assignee
>> is a core Jira field and cannot be replaced entirely by Authors.  However,
>> when we (hopefully later) get the ScriptRunner add-on, we might be able to
>> manage it transparently.
>> 
>> In the meantime, I don’t see any harm in introducing an Author field
>> anyway.  Does anyone have any objections?
>> -
>> 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: TLP tools for stress testing and building test clusters in AWS

[Aleksey Yeshchenko]

Hey Jon,

This sounds exciting and pretty useful, thanks.

Looking forward to using tlp-stress for validating 15066 performance.

We should touch base some time next week to pick a comprehensive set of 
workloads and versions, perhaps?


> On 12 Apr 2019, at 16:34, Jon Haddad  wrote:
> 
> I don't want to derail the discussion about Stabilizing Internode
> Messaging, so I'm starting this as a separate thread.  There was a
> comment that Josh made [1] about doing performance testing with real
> clusters as well as a lot of microbenchmarks, and I'm 100% in support
> of this.  We've been working on some tooling at TLP for the last
> several months to make this a lot easier.  One of the goals has been
> to help improve the 4.0 testing process.
> 
> The first tool we have is tlp-stress [2].  It's designed with a "get
> started in 5 minutes" mindset.  My goal was to ship a stress tool that
> ships with real workloads out of the box that can be easily tweaked,
> similar to how fio allows you to design a disk workload and tweak it
> with paramaters.  Included are stress workloads that stress LWTs (two
> different types), materialized views, counters, time series, and
> key-value workloads.  Each workload can be modified easily to change
> compaction strategies, concurrent operations, number of partitions.
> We can run workloads for a set number of iterations or a custom
> duration.  We've used this *extensively* at TLP to help our customers
> and most of our blog posts that discuss performance use it as well.
> It exports data to both a CSV format and auto sets up prometheus for
> metrics collection / aggregation.  As an example, we were able to
> determine that the compression length set on the paxos tables imposes
> a significant overhead when using the Locking LWT workload, which
> simulates locking and unlocking of rows.  See CASSANDRA-15080 for
> details.
> 
> We have documentation [3] on the TLP website.
> 
> The second tool we've been working on is tlp-cluster [4].  This tool
> is designed to help provision AWS instances for the purposes of
> testing.  To be clear, I don't expect, or want, this tool to be used
> for production environments.  It's designed to assist with the
> Cassandra build process by generating deb packages or re-using the
> ones that have already been uploaded.  Here's a short list of the
> things you'll care about:
> 
> 1. Create instances in AWS for Cassandra using any instance size and
> number of nodes.  Also create tlp-stress instances and a box for
> monitoring
> 2. Use any available build of Cassandra, with a quick option to change
> YAML config.  For example: tlp-stress use 3.11.4 -c
> concurrent_writes:256
> 3. Do custom builds just by pointing to a local Cassandra git repo.
> They can be used the same way as #2.
> 4. tlp-stress is automatically installed on the stress box.
> 5. Everything's installed with pure bash.  I considered something more
> complex, but since this is for development only, it turns out the
> simplest tool possible works well and it means it's easily
> configurable.  Just drop in your own bash script starting with a
> number in a XX_script_name.sh format and it gets run.
> 6. The monitoring box is running Prometheus.  It auto scrapes
> Cassandra using the Instaclustr metrics library.
> 7. Grafana is also installed automatically.  There's a couple sample
> graphs there now.  We plan on having better default graphs soon.
> 
> For the moment it installs java 8 only but that should be easily
> fixable to use java 11 to test ZGC (it's on my radar).
> 
> Documentation for tlp-cluster is here [5].
> 
> There's still some things to work out in the tool, and we've been
> working hard to smooth out the rough edges.  I still haven't announced
> anything WRT tlp-cluster on the TLP blog, because I don't think it's
> quite ready for public consumption, but I think the folks on this list
> are smart enough to see the value in it even if it has a few warts
> still.
> 
> I don't consider myself familiar enough with the networking patch to
> give it a full review, but I am qualified to build tools to help test
> it and go through the testing process myself.  From what I can tell
> the patch is moving the codebase in a positive direction and I'd like
> to help build confidence in it so we can get it merged in.
> 
> We'll continue to build out and improve the tooling with the goal of
> making it easier for people to jump into the QA side of things.
> 
> Jon
> 
> [1] 
> https://lists.apache.org/thread.html/742009c8a77999f4b62062509f087b670275f827d0c1895bf839eece@%3Cdev.cassandra.apache.org%3E
> [2] https://github.com/thelastpickle/tlp-stress
> [3] http://thelastpickle.com/tlp-stress/
> [4] https://github.com/thelastpickle/tlp-cluster
> [5] http://thelastpickle.com/tlp-cluster/
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

Re: TLP tools for stress testing and building test clusters in AWS

[Aleksey Yeshchenko]

Wednesday and Thursday, either, at 9 AM pacific WFM.

> On 13 Apr 2019, at 13:31, Stefan Miklosovic 
>  wrote:
> 
> Hi Jon,
> 
> I would like be on that call too but I am off on Thursday.
> 
> I am from Australia so 5pm London time is ours 2am next day so your
> Wednesday morning is my Thursday night. Wednesday early morning so
> your Tuesday morning and London's afternoon would be the best.
> 
> Recording the thing would be definitely helpful too.
> 
> On Sat, 13 Apr 2019 at 07:45, Jon Haddad  wrote:
>> 
>> I'd be more than happy to hop on a call next week to give you both
>> (and anyone else interested) a tour of our dev tools.  Maybe something
>> early morning on my end, which should be your evening, could work?
>> 
>> I can set up a Zoom conference to get everyone acquainted.  We can
>> record and post it for any who can't make it.
>> 
>> I'm thinking Tuesday, Wednesday, or Thursday morning, 9AM Pacific (5pm
>> London)?  If anyone's interested please reply with what dates work.
>> I'll be sure to post the details back here with the zoom link in case
>> anyone wants to join that didn't get a chance to reply, as well as a
>> link to the recorded call.
>> 
>> Jon
>> 
>> On Fri, Apr 12, 2019 at 10:41 AM Benedict Elliott Smith
>>  wrote:
>>> 
>>> +1
>>> 
>>> I’m also just as excited to see some standardised workloads and test bed.  
>>> At the moment we’re benefiting from some large contributors doing their own 
>>> proprietary performance testing, which is super valuable and something 
>>> we’ve lacked before.  But I’m also keen to see some more representative 
>>> workloads that are reproducible by anybody in the community take shape.
>>> 
>>> 
>>>> On 12 Apr 2019, at 18:09, Aleksey Yeshchenko  
>>>> wrote:
>>>> 
>>>> Hey Jon,
>>>> 
>>>> This sounds exciting and pretty useful, thanks.
>>>> 
>>>> Looking forward to using tlp-stress for validating 15066 performance.
>>>> 
>>>> We should touch base some time next week to pick a comprehensive set of 
>>>> workloads and versions, perhaps?
>>>> 
>>>> 
>>>>> On 12 Apr 2019, at 16:34, Jon Haddad  wrote:
>>>>> 
>>>>> I don't want to derail the discussion about Stabilizing Internode
>>>>> Messaging, so I'm starting this as a separate thread.  There was a
>>>>> comment that Josh made [1] about doing performance testing with real
>>>>> clusters as well as a lot of microbenchmarks, and I'm 100% in support
>>>>> of this.  We've been working on some tooling at TLP for the last
>>>>> several months to make this a lot easier.  One of the goals has been
>>>>> to help improve the 4.0 testing process.
>>>>> 
>>>>> The first tool we have is tlp-stress [2].  It's designed with a "get
>>>>> started in 5 minutes" mindset.  My goal was to ship a stress tool that
>>>>> ships with real workloads out of the box that can be easily tweaked,
>>>>> similar to how fio allows you to design a disk workload and tweak it
>>>>> with paramaters.  Included are stress workloads that stress LWTs (two
>>>>> different types), materialized views, counters, time series, and
>>>>> key-value workloads.  Each workload can be modified easily to change
>>>>> compaction strategies, concurrent operations, number of partitions.
>>>>> We can run workloads for a set number of iterations or a custom
>>>>> duration.  We've used this *extensively* at TLP to help our customers
>>>>> and most of our blog posts that discuss performance use it as well.
>>>>> It exports data to both a CSV format and auto sets up prometheus for
>>>>> metrics collection / aggregation.  As an example, we were able to
>>>>> determine that the compression length set on the paxos tables imposes
>>>>> a significant overhead when using the Locking LWT workload, which
>>>>> simulates locking and unlocking of rows.  See CASSANDRA-15080 for
>>>>> details.
>>>>> 
>>>>> We have documentation [3] on the TLP website.
>>>>> 
>>>>> The second tool we've been working on is tlp-cluster [4].  This tool
>>>>> is designed to help provision AWS instances for the purposes of
>>>>> testing.  To be clear, 

Re: Acceptable for trunk? Committing the patch for "Customize cassandra log directory" (CASSANDRA-15090)

[Aleksey Yeshchenko]

Yeah. I wouldn’t even go and ask for a waiver for anything as trivial as this 
change.

Common sense of a committer should be sufficient.

> On 26 May 2019, at 09:31, Mick Semb Wever  wrote:
> 
> 
> The ticket CASSANDRA-15090 has a patch to introduce the variable 
> $CASSANDRA_LOG_DIR 
> 
> Strictly speaking it is not a bug, but it is a simple patch that would help 
> some operators.
> 
> Can I get a waiver on the feature freeze to commit this patch to trunk?
> 
> cheers,
> Mick
> 
> https://issues.apache.org/jira/browse/CASSANDRA-15090 
> 
> -
> 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: Java8 compatibility broken in 4.0

[Aleksey Yeshchenko]

No, this is not intentional. At the very least for 4.0 we are going to keep 
compatibility with Java 8.

> On 11 Jun 2019, at 10:04, Tommy Stendahl  wrote:
> 
> Hi,
> 
> I can't find a way to build 4.0 artifacts so I can run Cassandra using Java8. 
> Building the artifacts ("ant artifacts" or "ant mvn-install") requires 
> building with Java11 but since CASSANDRA-15108 the result is not Java8 
> compatible anymore, is this intentional or was this done by mistake?
> 
> I also tried to change this back and force Java11 to build Java8 compatible 
> code but it seams that there are some  changes in the ByetBuffer 
> implementation in Java11 that breaks when execution in a Java8 jvm, when I 
> started Cassandra it throws a NoSuchMethodError when trying to open the 
> sstables.
> 
> 2019-05-28T16:20:24.506+0200 [SSTableBatchOpen:4] ERROR 
> o.a.c.i.s.format.SSTableReader$2:576 run Corrupt sstable 
> /var/lib/cassandra/data/system/sstable_activity-5a1ff267ace03f128563cfae6103c65e/mc-2202-big=[CompressionInfo.db,
>  TOC.txt, Statistics.db, Summary.db, Index.db, Data.db, Filter.db, 
> Digest.crc32]; skipping table
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted: 
> /var/lib/cassandra/data/system/sstable_activity-5a1ff267ace03f128563cfae6103c65e/mc-2202-big-Statistics.db
>at 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:504)
>at 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:375)
>at 
> org.apache.cassandra.io.sstable.format.SSTableReader$2.run(SSTableReader.java:571)
>at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NoSuchMethodError: 
> java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
>at 
> org.apache.cassandra.utils.memory.BufferPool.allocateDirectAligned(BufferPool.java:528)
>at 
> org.apache.cassandra.utils.memory.BufferPool.access$600(BufferPool.java:46)
>at 
> org.apache.cassandra.utils.memory.BufferPool$GlobalPool.allocateMoreChunks(BufferPool.java:279)
>at 
> org.apache.cassandra.utils.memory.BufferPool$GlobalPool.get(BufferPool.java:248)
>at 
> org.apache.cassandra.utils.memory.BufferPool$LocalPool.addChunkFromGlobalPool(BufferPool.java:354)
>at 
> org.apache.cassandra.utils.memory.BufferPool$LocalPool.get(BufferPool.java:397)
>at 
> org.apache.cassandra.utils.memory.BufferPool.maybeTakeFromPool(BufferPool.java:143)
>at 
> org.apache.cassandra.utils.memory.BufferPool.takeFromPool(BufferPool.java:115)
>at org.apache.cassandra.utils.memory.BufferPool.get(BufferPool.java:94)
>at 
> org.apache.cassandra.io.util.BufferManagingRebufferer.(BufferManagingRebufferer.java:45)
>at 
> org.apache.cassandra.io.util.BufferManagingRebufferer$Unaligned.(BufferManagingRebufferer.java:117)
>at 
> org.apache.cassandra.io.util.SimpleChunkReader.instantiateRebufferer(SimpleChunkReader.java:60)
>at 
> org.apache.cassandra.io.util.RandomAccessReader.open(RandomAccessReader.java:319)
>at 
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:126)
>at 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:500)
>... 8 common frames omitted
> 
> The reason for this is that some methods in the ByteBuffer implementation in 
> Java11 returns a Bytebuffer but in Java8 and before they returned a Buffer. I 
> found a bit of information on Stackoverflow 
> (https://stackoverflow.com/questions/48693695/java-nio-buffer-not-loading-clear-method-on-runtime)
>  so there seams to be a way to fix this even if the resulting code looks ugly 
> to me.
> 
> My question is, are we intentionally giving up Java8 comparability in 4.0 or 
> do we still want to support Java8?
> 
> Regards,
> Tommy


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: 4.0 alpha before apachecon?

[Aleksey Yeshchenko]

Not really important IMO if we do or do not cut a new branch yet. So let’s hold 
off?

But as mentioned on Slack, I really like the idea of cutting an alpha now, with 
clear understanding that the API will still slightly change before the 4.0-GA.

There is enough complete work in trunk that will *not* change between now and 
GA that could benefit from user testing already.

> On 30 Aug 2019, at 12:46, Mick Semb Wever  wrote:
> 
> 
>> 
>> Let's just pull the trigger on it. We know there are a couple of rough
>> edges, but that is the point of an alpha.
> 
> 
> Is the idea to also cut 2.2.15, 3.0.19, and 3.11.5, at the same time as 
> 4.0-alpha1 ?
> 
> (Michael, have you the cycles for this?)
> 
> regards,
> Mick
> 
> -
> 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-2] Apache Cassandra Release Lifecycle

[Aleksey Yeshchenko]

+1 as a rather reasonable starting point; we can make changes to the process in 
the future if need be.

> On 8 Oct 2019, at 19:00, sankalp kohli  wrote:
> 
> Hi,
>We have discussed in the email thread[1] about Apache Cassandra Release
> Lifecycle. We came up with a doc[2] for it. We have finalized the doc
> here[3] Please vote on it if you agree with the content of the doc [3].
> 
> We did not proceed with the previous vote as we want to use confluence for
> it. Here is the link for that[4]. It also mentions why we are doing this
> vote.
> 
> Vote will remain open for 72 hours.
> 
> Thanks,
> Sankalp
> 
> [1]
> https://lists.apache.org/thread.html/c610b23f9002978636b66d09f0e0481ed3de9b78895050da22c91c6f@%3Cdev.cassandra.apache.org%3E
> [2]
> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#heading=h.633eppni91tw
> [3]https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
> Attachments area
> [4]
> https://lists.apache.org/thread.html/169b00f45dbad295e1aea1da70365fabc8452ef497f78ddfd28c311f@%3Cdev.cassandra.apache.org%3E
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Protocol-impacting (internode and client) changes for 4.0

[Aleksey Yeshchenko]

+1; in particular since the protocol itself is still in beta

> On 9 Oct 2019, at 17:26, Oleksandr Petrov  wrote:
> 
> Hi,
> 
> During NGCC/ACNA19 we've had quite a few conversations around the 4.0
> release. Many (minor) features and changes suggested during that time are
> possible to implement in 4.next without any problem. However, some changes
> that seem to be very important for the community, which got mentioned in
> several conversations, are not possible to implement without protocol
> changes. By *protocol* changes here I mean both native and client protocol.
> 
> Here's a shortlist of the issues in question:
> https://issues.apache.org/jira/browse/CASSANDRA-15349 Add “Going away”
> message to the client protocol
> https://issues.apache.org/jira/browse/CASSANDRA-15350 Add CAS “uncertainty”
> and “contention" messages that are currently propagated as a
> WriteTimeoutException.
> https://issues.apache.org/jira/browse/CASSANDRA-15351 Allow configuring
> timeouts on the per-request basis
> https://issues.apache.org/jira/browse/CASSANDRA-15352 Replica failure
> propagation to coordinator and client
> https://issues.apache.org/jira/browse/CASSANDRA-15299 Improve checksumming
> and compression in protocol v5-beta
> 
> And, less importantly - CASSANDRA-14683 (paging state issue).
> 
> My suggestion would be to lift a freeze for all (or at least some) of these
> issues, since they seem to be quite important for operators and each one of
> them is extremely low risk, which means that any validation effort that has
> already happened won't have to be re-done. All of the issues are fairly
> easy to implement, which means they won't delay the release.
> 
> To my best knowledge, there's no client that fully supports 4.0, I think
> doing this now actually makes sense, meaning that driver implementers won't
> really have to redo anything.
> 
> Your thoughts on this are welcome,
> -- Alex


-
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-alpha2

[Aleksey Yeshchenko]

+1

> On 24 Oct 2019, at 18:26, Michael Shuler  wrote:
> 
> I propose the following artifacts for release as 4.0-alpha2.
> 
> sha1: ca928a49c68186bdcd57dea8b10c30991c6a3c55
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha2-tentative
> Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1185/org/apache/cassandra/apache-cassandra/4.0-alpha2/
> Staging repository: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1185/
> 
> The Debian and RPM packages are available here: 
> http://people.apache.org/~mshuler
> 
> The vote will be open for 72 hours (longer if needed).
> 
> [1]: CHANGES.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-alpha2-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-alpha2-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 2.2.15

[Aleksey Yeshchenko]

+1

> On 24 Oct 2019, at 18:25, Michael Shuler  wrote:
> 
> I propose the following artifacts for release as 2.2.15.
> 
> sha1: 4ee4ceea28a1cb77b283c7ce0135340ddff02086
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.15-tentative
> Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1179/org/apache/cassandra/apache-cassandra/2.2.15/
> Staging repository: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1179/
> 
> The Debian and RPM packages are available here: 
> http://people.apache.org/~mshuler
> 
> The vote will be open for 72 hours (longer if needed).
> 
> [1]: CHANGES.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.15-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/2.2.15-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.5

[Aleksey Yeshchenko]

+1

> On 24 Oct 2019, at 18:26, Michael Shuler  wrote:
> 
> I propose the following artifacts for release as 3.11.5.
> 
> sha1: b697af87f8e1b20d22948390d516dba1fbb9eee7
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.5-tentative
> Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1184/org/apache/cassandra/apache-cassandra/3.11.5/
> Staging repository: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1184/
> 
> The Debian and RPM packages are available here: 
> http://people.apache.org/~mshuler
> 
> The vote will be open for 72 hours (longer if needed).
> 
> [1]: CHANGES.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.5-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.5-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.19

[Aleksey Yeshchenko]

+1

> On 24 Oct 2019, at 18:25, Michael Shuler  wrote:
> 
> I propose the following artifacts for release as 3.0.19.
> 
> sha1: a81bfd6b7db3a373430b3c4e8f4e930b199796f0
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.19-tentative
> Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1183/org/apache/cassandra/apache-cassandra/3.0.19/
> Staging repository: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1183/
> 
> The Debian and RPM packages are available here: 
> http://people.apache.org/~mshuler
> 
> The vote will be open for 72 hours (longer if needed).
> 
> [1]: CHANGES.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.19-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.19-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: Improvements on C* v3.11

[Aleksey Yeshchenko]

Normally we prefer new features to go to trunk.

In some rare cases, when the risk is low and the value of a new feature is 
high, we make exceptions - but usually early in a major version life cycle, and 
mostly in the past, when we were a lot more lax about such things.

In this particular case I think 4.0(+) is the right major version for this 
change to land on.

> On 12 Nov 2019, at 22:25, Ekaterina Dimitrova 
>  wrote:
> 
> Hello,
> According to the official Cassandra web page no new features could be
> submitted for version 3.11. I am not sure whether this also covers some
> small improvements?
> Short example - CASSANDRA-12197
> 
> Thank you in advance
> 
> Best regards,
> Ekaterina Dimitrova | Software Engineer
> ekaterina.dimitr...@datastax.com | datastax.com
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] Switch to using GitHub pull requests?

[Aleksey Yeshchenko]

The person introducing flakiness to a test will almost always have run it 
locally and on CI first with success. It’s usually later when they first start 
failing, and it’s often tricky to attribute to a particular commit/person.

So long as we have these - and we’ve had flaky tests for as long as C* has 
existed - the problem will persist, and gating PRs on clean runs won’t achieve 
anything other than dealing with folks who straight up ignore the spirit of the 
policy and knowingly commit code with test breakage that can be attributed to 
their change. I’m not aware of such committers in this community, however.

> On 24 Jan 2020, at 09:01, Benedict Elliott Smith  wrote:
> 
>> I find it only useful for nits, or for coaching-level comments that I would 
>> never want propagated to Jira.
> 
> Actually, I'll go one step further. GitHub encourages comments that are too 
> trivial, poisoning the well for third parties trying to find useful 
> information.  If the comment wouldn't be made in Jira, it probably shouldn't 
> be made. 
> 
> 
> 
> On 24/01/2020, 08:56, "Benedict Elliott Smith"  wrote:
> 
>The common factor is flaky tests, not people.  You get a clean run, you 
> commit.  Turns out, a test was flaky.  This reduces trust in CI, so people 
> commit without looking as closely at results.  Gating on clean tests doesn't 
> help, as you run until you're clean.  Rinse and repeat.  Breakages 
> accumulate.  
> 
>This is what happens leading up to every release - nobody commits knowing 
> there's a breakage.  We have a problem with bad tests, not bad people or 
> process.
> 
>FWIW, I no longer like the GitHub workflow.  I find it only useful for 
> nits, or for coaching-level comments that I would never want propagated to 
> Jira.  I find a strong patch submission of any size is better managed with 
> human-curated Jira comments, and provides a better permanent record.  When 
> skimming a discussion, Jira is more informative than GitHub.  Even with the 
> GitHub UX, the context hinders rather than helps.
> 
>As to propagating to Jira: has anyone here ever read them?  I haven't as 
> they're impenetrable; ugly and almost entirely noise.  If anything, I would 
> prefer that we discourage GitHub for review as a project, not move towards it.
> 
>This is without getting into the problem of multiple branch PRs.  Until 
> this is _provably_ painless, we cannot introduce a workflow that requires it 
> and blocks commit on it.  Working with multiple branches is difficult enough 
> already, surely?
> 
> 
> 
>On 24/01/2020, 03:16, "Jeff Jirsa"  wrote:
> 
>100% agree
> 
>François and team wrote a doc on testing and gating commits
>Blake wrote a doc on testing and gating commits
>Every release there’s a thread on testing and gating commits
> 
>People are the common factor every time. Nobody wants to avoid merging 
> their patch because someone broke a test elsewhere. 
> 
>We can’t block merging technically with the repo as it exists now so 
> it’s always going to come down to people and peer pressure, until or unless 
> someone starts reverting commits that break tests
> 
>(Of course, someone could write a tool that automatically reverts new 
> commits as long as tests fail)
> 
>On Jan 23, 2020, at 5:54 PM, Joshua McKenzie  
> wrote:
>> 
>> 
>>> 
>>> 
>>> I am reacting to what I currently see
>>> happening in the project; tests fail as the norm and this is kinda seen as
>>> expected, even though it goes against the policies as I understand it.
>> 
>> After over half a decade seeing us all continue to struggle with this
>> problem, I've come around to the school of "apply pain" (I mean that as
>> light-hearted as you can take it) when there's a failure to incent fixing;
>> specifically in this case, the only idea I can think of is preventing merge
>> w/any failing tests on a PR. We go through this cycle as we approach each
>> major release: we have the gatekeeper of "we're not going to cut a release
>> with failing tests obviously", and we clean them up. After the release, the
>> pressure is off, we exhale, relax, and flaky test failures (and others)
>> start to creep back in.
>> 
>> If the status quo is the world we want to live in, that's totally fine and
>> no judgement intended - we can build tooling around test failure history
>> and known flaky tests etc to optimize engineer workflows around that
>> expectation. But what I keep seeing on threads like this (and have always
>> heard brought up in conversation) is that our collective *moral* stance is
>> that we should have green test boards and not merge code if it introduces
>> failing tests.
>> 
>> Not looking to prescribe or recommend anything, just hoping that
>> observation above might be of interest or value to the conversation.
>> 
>>> On Thu, Jan 23, 2020 at 4:17 PM Michael Shuler 
>>> wrote:
>>> 
 On 1/23/20 3:53 PM, David Capwell wrote:
 
 2) Nightly bu

Re: [DISCUSS] Switch to using GitHub pull requests?

[Aleksey Yeshchenko]

As for GH for code review, I find that it works very well for nits. It’s also 
great for doc changes, given how GH allows you suggest changes to files 
in-place and automatically create PRs for those changes. That lowers the 
barrier for those tiny contributions.

For anything relatively substantial, I vastly prefer to summarise my feedback 
(and see others’ feedback summarised) in JIRA comments - an opinion I and other 
contributors have shared in one or two similar threads over the years.


> On 24 Jan 2020, at 12:21, Aleksey Yeshchenko  
> wrote:
> 
> The person introducing flakiness to a test will almost always have run it 
> locally and on CI first with success. It’s usually later when they first 
> start failing, and it’s often tricky to attribute to a particular 
> commit/person.
> 
> So long as we have these - and we’ve had flaky tests for as long as C* has 
> existed - the problem will persist, and gating PRs on clean runs won’t 
> achieve anything other than dealing with folks who straight up ignore the 
> spirit of the policy and knowingly commit code with test breakage that can be 
> attributed to their change. I’m not aware of such committers in this 
> community, however.
> 
>> On 24 Jan 2020, at 09:01, Benedict Elliott Smith  wrote:
>> 
>>> I find it only useful for nits, or for coaching-level comments that I would 
>>> never want propagated to Jira.
>> 
>> Actually, I'll go one step further. GitHub encourages comments that are too 
>> trivial, poisoning the well for third parties trying to find useful 
>> information.  If the comment wouldn't be made in Jira, it probably shouldn't 
>> be made. 
>> 
>> 
>> 
>> On 24/01/2020, 08:56, "Benedict Elliott Smith"  wrote:
>> 
>>   The common factor is flaky tests, not people.  You get a clean run, you 
>> commit.  Turns out, a test was flaky.  This reduces trust in CI, so people 
>> commit without looking as closely at results.  Gating on clean tests doesn't 
>> help, as you run until you're clean.  Rinse and repeat.  Breakages 
>> accumulate.  
>> 
>>   This is what happens leading up to every release - nobody commits knowing 
>> there's a breakage.  We have a problem with bad tests, not bad people or 
>> process.
>> 
>>   FWIW, I no longer like the GitHub workflow.  I find it only useful for 
>> nits, or for coaching-level comments that I would never want propagated to 
>> Jira.  I find a strong patch submission of any size is better managed with 
>> human-curated Jira comments, and provides a better permanent record.  When 
>> skimming a discussion, Jira is more informative than GitHub.  Even with the 
>> GitHub UX, the context hinders rather than helps.
>> 
>>   As to propagating to Jira: has anyone here ever read them?  I haven't as 
>> they're impenetrable; ugly and almost entirely noise.  If anything, I would 
>> prefer that we discourage GitHub for review as a project, not move towards 
>> it.
>> 
>>   This is without getting into the problem of multiple branch PRs.  Until 
>> this is _provably_ painless, we cannot introduce a workflow that requires it 
>> and blocks commit on it.  Working with multiple branches is difficult enough 
>> already, surely?
>> 
>> 
>> 
>>   On 24/01/2020, 03:16, "Jeff Jirsa"  wrote:
>> 
>>   100% agree
>> 
>>   François and team wrote a doc on testing and gating commits
>>   Blake wrote a doc on testing and gating commits
>>   Every release there’s a thread on testing and gating commits
>> 
>>   People are the common factor every time. Nobody wants to avoid merging 
>> their patch because someone broke a test elsewhere. 
>> 
>>   We can’t block merging technically with the repo as it exists now so 
>> it’s always going to come down to people and peer pressure, until or unless 
>> someone starts reverting commits that break tests
>> 
>>   (Of course, someone could write a tool that automatically reverts new 
>> commits as long as tests fail)
>> 
>>   On Jan 23, 2020, at 5:54 PM, Joshua McKenzie  
>> wrote:
>>> 
>>> 
>>>> 
>>>> 
>>>> I am reacting to what I currently see
>>>> happening in the project; tests fail as the norm and this is kinda seen as
>>>> expected, even though it goes against the policies as I understand it.
>>> 
>>> After over half a decade seeing us all continue to struggle with this
>>> problem, I've come around to the school of "apply pain" (I mean that as

Re: [DISCUSS] Client protocol changes (Was: 20200217 4.0 Status Update)

[Aleksey Yeshchenko]

For what it’s worth, we could trivially implement support for passing down the 
timeout in 4.0.0, so that both the server and the client are able to parse the 
frames with and without them, but delay implementation of the server side logic 
necessary for terminating requests early until a further minor (4.1/4.0.1).

> On 19 Feb 2020, at 15:39, Jorge Bay Gondra  wrote:
> 
> Also worth mentioning that, from the driver's perspective, it has to
> support a protocol version during the lifetime of the C* version line. For
> example, the drivers should drop support for protocol v3 after C* 2.1 goes
> EOL, somewhere this year, a protocol that was released back in 2014.
> 
> We _could_ establish looser restrictions on whats a breaking change in a
> protocol version (needing a version bump), that way the driver can support
> a protocol version partially and a protocol version could evolve within
> those limits.
> 
> Back to the query timeout, a new query flag that can only be set by the
> client is not a breaking change for the driver. The driver could ask
> whether that feature of the protocol v5 is supported (OPTIONS/SUPPORTED
> messages), without having to identify the server version.
> 
> On Wed, Feb 19, 2020 at 12:24 AM Benedict Elliott Smith 
> wrote:
> 
>> Behaviours don't have to be switched only with a new protocol version;
>> it's possible to support optional feature/modifier flags, the support for
>> which is negotiated with a client on connection.
>> 
>> A protocol version change seems reasonable to limit to major releases, but
>> a protocol feature seems perfectly reasonable to introduce in a minor, I
>> think?  Ideally a version change would only be necessary for forced
>> deprecation/standardisation of features, behaviour and stream encodings.
>> 
>> 
>> On 18/02/2020, 21:53, "Jeff Jirsa"  wrote:
>> 
>>A few notes:
>> 
>>- Protocol changes add work to the rest of the ecosystem. Drivers have
>> to
>>update, etc.
>>- Nobody expects protocol changes in minors, though it's less of a
>> concern
>>if we don't deprecate out the older version. E.g. if 4.0 launches with
>>protocol v4 and protocol v5, and then 4.0.2 adds protocol v6, do we
>>deprecate out v4? If yes, you potentially break clients that only
>> supported
>>v3 and v4 in a minor version upgrade, which is unexpected. If not, how
>> many
>>protocol versions are you willing to support at any given time?
>>- Having protocol changes introduces risk. Paging behavior across
>> protocol
>>versions is the site of a number of different bugs recently.
>> 
>> 
>>On Tue, Feb 18, 2020 at 1:46 PM Tolbert, Andrew 
>> wrote:
>> 
>>> I don't know the technical answer, but I suspect two motivations for
>>> doing new protocol versions in major releases could include:
>>> 
>>> * protocol changes can be tied to feature changes that typically come
>>> in a major release.
>>> * protocol changes should be as infrequent as major releases.  Each
>>> new protocol version is another thing in the test matrix that needs
>> to
>>> be tested.
>>> 
>>> That last point can make it hard to get new changes in. If something
>>> doesn't make the upcoming protocol version, it might be years before
>>> another one, but I also think it's worth it to do this infrequently
>> as
>>> it makes maintaining client and server code easier if there are less
>>> protocol versions to worry about.
>>> 
>>> On the client-side, libraries themselves should be avoiding making
>>> Cassandra version checks when detecting capabilities.  There are a
>> few
>>> exceptions, such as system table parsing for schema & peers,
>>> but those aren't related to the protocol.
>>> 
>>> Thanks,
>>> Andy
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Tue, Feb 18, 2020 at 1:22 PM Nate McCall 
>> wrote:
 
 [Moving to new message thread]
 
 Thanks for bringing this up, Jordan.
 
 IIRC, this was more a convention than a technical reason. Though I
>> could
>>> be
 completely misremembering this.
 
 -- Forwarded message -
 From: Jordan West 
 Date: Wed, Feb 19, 2020 at 10:13 AM
 Subject: Re: 20200217 4.0 Status Update
 To: 
 
 
 On Mon, Feb 17, 2020 at 12:52 PM Jeff Jirsa 
>> wrote:
 
> 
> beyond the client proto change being painful for anything other
>> than
>>> major
> releases
> 
> 
 This came up during the community meeting today and I wanted to
>> bring a
 question about it to the list: could someone who is *very*
>> familiar with
 the client proto share w/ the list why changing the proto in
>> anything
>>> other
 than a major release is so difficult? I hear this a lot and it
>> seems to
>>> be
 fact. So that all of us don't have to go read the code, a brief
>> summary
 would be super helpful. Or if there is a ticket that already
>> covers this
 even better! I'd also be curious if there have ever been any
>> thoughts to
 address it as it seems to be a consi

Re: server side describe

[Aleksey Yeshchenko]

Yeah, I feel like it’s a bad example to use to highlight 4.0 scope creep (which 
is less of a thing than some fear).

The work there is already done, and it’s extremely unintrusive. There is no 
reason whatsoever to block 4.0 on it, but no reason not to commit - now, in a 
beta, in the first RC, or even later in a minor.

> On 2 Apr 2020, at 17:40, Benedict Elliott Smith  wrote:
> 
> Sorry if this is a repeat message; I messed up my mail client settings (I 
> don't see it today, but it might just be stuck in an unmonitored moderator 
> queue):
> 
> I think it is unfair to label this scope creep; it would have to be newly 
> considered for 4.0 for it to fall under that umbrella, surely?
> 
> I don't personally mind if it lands, but this was discussed at length on 
> multiple occasions over the past year, and only stalled because of a 
> combination of lack of etiquette, and a lack of leadership from e.g. PMC in 
> resolving various primarily political questions over the course of events.
> 
> I also struggle to see how this would invalidate testing in any significant 
> way?  It doesn't modify any existing behaviour.
> 
> 
> On 02/04/2020, 09:08, "Benjamin Lerer"  wrote:
> 
>+1 for shipping it after 4.0
> 
> 
> 
>On Thu, Apr 2, 2020 at 12:39 AM Jon Haddad  wrote:
> 
>> Most of the work to provide this feature is already done.  We need to
>> generate server side CQL for snapshots already.  All we need to do is
>> expose it via either a "DESCRIBE" CQL command, or I'm equally happy to see
>> it land in a virtual table.
>> 
>> On Wed, Apr 1, 2020 at 2:45 PM sankalp kohli 
>> wrote:
>> 
>>> +1 on holding off and focus on shipping 4.0
>>> 
>>> On Wed, Apr 1, 2020 at 12:25 PM Joshua McKenzie 
>>> wrote:
>>> 
 This looks like a feature that'd potentially invalidate some testing
>>> that's
 been done and we've been feature frozen for over a year and a half.
>> Also:
 scope creep.
 
 My PoV is we hold off. If we get into a cadence of more frequent
>> releases
 we'll have it soon enough.
 
 On Wed, Apr 1, 2020 at 3:03 PM  wrote:
 
> Hi,
> Normally I ping the person on the ticket or in Slack to ask him/her
>> for
> status update and whether I can help. Then probably he/she gives me a
> direction.
> If I can’t find the person anymore, I just use my best judgement and
> coordinate with people who might know better than me.
> For now this strategy worked for me personally.
> Hope this helps
> Ekaterina
> 
> Sent from my iPhone
> 
>> On 1 Apr 2020, at 14:27, Jon Haddad  wrote:
>> 
>> Hey folks,
>> 
>> I was looking through our open JIRAs and realized we hadn't merged
>> in
>> server side describe calls yet.  The ticket died off a ways ago,
>> and
>>> I
>> pinged Chris about it yesterday.  He's got a lot of his plate and
>>> won't
> be
>> able to work on it anytime soon.  I still think we should include
>>> this
 in
>> 4.0.
>> 
>> From a technical standpoint, It doesn't say much on the ticket
>> after
> Robert
>> tossed an alternative patch out there.  I don't mind reviewing and
> merging
>> either of them, it sounded like both are pretty close to done and I
 think
>> from the perspective of updating drivers for 4.0 this will save
>>> quite a
> bit
>> of time since driver maintainers won't have to add new CQL
>> generation
 for
>> the various new options that have recently appeared.
>> 
>> Questions:
>> 
>> * Does anyone have an objection to getting this into 4.0? The
>> patches
>> aren't too huge, I think they're low risk, and also fairly high
>>> reward.
>> * I don't have an opinion (yet) on Robert's patch vs Chris's, with
 regard
>> to which is preferable.
>> * Since soon after Robert put up his PR he hasn't been around, at
>>> least
> as
>> far as I've seen.  How have we dealt with abandoned patches before?
>>> If
>> we're going to add this in the patch will need some cleanup.  Is it
>> reasonable to continue someone else's work when they've
>> disappeared?
>> 
>> Jon
> 
> -
> 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: Keeping test-only changes out of CHANGES.txt

[Aleksey Yeshchenko]

+1

> On 8 Apr 2020, at 15:08, Mick Semb Wever  wrote:
> 
> Can we agree on keeping such test changes out of CHANGES.txt ?
> 
> We already don't put entries into CHANGES.txt if it is not a change
> from any previous release.
> 
> There was some discussion before¹ about this, and the problem that
> being selective meant what ended up there being arbitrary. I think
> this can be solved with an easy rule of thumb that if it only touches
> *Test.java classes, or it is only about fixing a test, then it
> shouldn't be in CHANGES.txt. That means if the patch does touch any
> runtime code then you do still need to add an entry to CHANGES.txt.
> This avoids the whole "arbitrary" problem,  and maintains CHANGES.txt
> as user-facing formatted text to be searched through.
> 
> If there's agreement I can commit to going through 4.0 changes and
> removing those that never touched runtime code.
> 
> regards,
> Mick
> 
> ¹) 
> https://lists.apache.org/thread.html/a94946887081d8a408dd5cd01a203664f4d0197df713f0c63364a811%40%3Cdev.cassandra.apache.org%3E
> 
> -
> 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-alpha4

[Aleksey Yeshchenko]

+1

> On 11 Apr 2020, at 00:02, Mick Semb Wever  wrote:
> 
> Proposing the test build of Cassandra 4.0-alpha4 for release.
> 
> sha1: d00c004cc10986fc41c2070f9c5d0007e03a45c3
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha4-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1202/org/apache/cassandra/cassandra-all/4.0-alpha4/
> 
> 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-alpha4/
> 
> The vote will be open for at least 96 hours (longer than normal,
> because of Easter holidays for many). Everyone who has tested the
> build is invited to vote. Votes by PMC members are considered binding.
> A vote passes if there are at least three binding +1s.
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-alpha4-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-alpha4-tentative
> 
> 
> regards,
> Mick
> 
> -
> 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: Simplify voting rules for in-jvm-dtest-api releases

[Aleksey Yeshchenko]

+1

> On 15 Apr 2020, at 14:35, Oleksandr Petrov  wrote:
> 
> Hi everyone,
> 
> Apache release rules were made for first-class projects. I would like to
> propose simplifying voting rules for in-jvm-dtest-api project [1].
> 
> A bit of background: in-jvm-dtest-api is a project that is used by all
> active Cassandra branches (2.2, 3.0, 3.11, and trunk) to unify interfaces
> that allows creating clusters and running tests, much like Python dtests,
> just with a potential to run and develop them faster. Previously, anyone
> could break API compatibility by committing to only one of the branches and
> not updating the other one, which has happened on several occasions and has
> went unnoticed, and has added work for people who had to bring changes to
> more than one branch. This unified API and tests are particularly useful
> for upgrade tests, but are also good for any kind of testing.
> 
> Since this project was made to simplify contributions to in-jvm dtests,
> it'd be great if making changes to this project would actually be simple.
> Before that, in order to make changes in in-jvm-dtest API, we required
> only +1 from a contributor and a committer could just commit the change.
> 
> I would say that in order to cut a (minor) release of in-jvm-dtest-api you
> should:
> 
> 1. Get a +1 from a contributor who can review and test your change
> 2. Get a +1 from one of committers who are familiar with in-jvm dtests (we
> have enough, I just don't want to volunteer anyone)
> 
> This will guard us from unnecessary changes, and add an extra pair of eyes
> for things that influence moore than one branch, but leave us flexible
> enough to be able to move forward without conducting a vote.
> 
> Since in-jvm-dtest-api is only used to test Cassandra, and isn't intended
> for production purposes, this is a low-risk change in procedure. Moreover,
> even if we package in-jvm-dtest-api with some Cassandra release, there will
> be an additional vote on the release, where anyone who has concerns about
> in-jvm-dtest-api changes can still voice them.
> 
> Please let me know if you'd like more information about in-jvm-dtest API,
> or have comments about this change in procedure.
> 
> Thank you,
> -- Alex
> [1] https://github.com/apache/cassandra-in-jvm-dtest-api


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Discussion: addition to CEP guide

[Aleksey Yeshchenko]

+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: Calling for release managers (Committers and PMC)

[Aleksey Yeshchenko]

Please add me as well.

> On 12 May 2020, at 09:51, Sam Tunnicliffe  wrote:
> 
> Me too.
> 
>> On 11 May 2020, at 20:23, Jake Luciani  wrote:
>> 
>> Happy to lend a hand
>> 
>> On Mon, May 11, 2020 at 3:12 PM Eric Evans 
>> wrote:
>> 
>>> I can take a turn.
>>> 
>>> On Fri, May 8, 2020 at 11:10 AM Vinay Chella 
>>> wrote:
 
 I would like to help as well.
 
 
 On Fri, May 8, 2020 at 8:54 AM Chris Lohfink 
>>> wrote:
 
> I'd like to get involved in this as well.
> 
> On Thu, May 7, 2020 at 2:06 PM Jon Meredith 
>>> wrote:
> 
>> Sign me up.
>> 
>> On Thu, May 7, 2020 at 12:36 PM Robert Stupp  wrote:
>>> 
>>> I can help
>>> 
>>> --
>>> Robert Stupp
>>> @snazy
>>> 
 Am 07.05.2020 um 20:29 schrieb Mick Semb Wever :
 
 The Cassandra release process has had some improvements to
>>> better in
 line with the ASF guidelines: sha256 & sha512 checksums, staged
 artefacts in svnpubsub, dep and rpm repositories complete and
>>> signed
 in staging, and separate scripts and manual steps merged
>>> together.
 
 The updated documentation for cutting, voting, and publishing a
 release is found here:
 
>> 
>>> https://cassandra.apache.org/doc/latest/development/release_process.html
 
 I am hoping to get as many Committers* and PMC members
>>> interested as
 possible for cutting a future release.
 
 Who is interested? How many names can I get :-)
 
 The more that are interested then the easier it is to take turns
>>> and
 be flexible depending on our own availability each time. I will
>>> help
 out everyone on their first run. Indeed most of my motivation in
 getting involved with the release process was to make it all as
> simple
 and as forgettable as possible, so the role of the role manager
>>> can
 change easily from release to release.
 
 *When a Committer cuts a release, a PMC member has to perform the
> very
 last post-vote publish step.
 
 regards,
 Mick
 
 
>>> -
 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
>> 
>> 
> 
 --
 
 Thanks,
 Vinay Chella
>>> 
>>> 
>>> 
>>> --
>>> 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
>>> 
>>> 
> 
> 
> -
> 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)

[Aleksey Yeshchenko]

+1

> On 20 Jun 2020, at 16:12, 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


-
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.21

[Aleksey Yeshchenko]

+1

> On 14 Jul 2020, at 23:49, Mick Semb Wever  wrote:
> 
> Proposing the test build of Cassandra 3.0.21 for release.
> 
> sha1: e39d1da325f5853ab3a64d92ecf52f8271239b9e
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.21-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1208/org/apache/cassandra/cassandra-all/3.0.21/
> 
> 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.21/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s.
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.21-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.21-tentative


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [Vote] Remove Windows support from 4.0+

[Aleksey Yeshchenko]

+1

> On 10 Aug 2020, at 04:14, Yuki Morishita  wrote:
> 
> As per the discussion(*), I propose to remove Windows support from 4.0
> release and onward.
> 
> Windows scripts are not maintained and we lack windows test
> environments. WIndows users can  use docker or cloud environments to
> set up Cassandra application development.
> 
> If the vote pass, I will create the following tickets to officially
> remove Windows support from 4.0:
> 
> - Remove Windows scripts and add notice to NEWS.txt
> - Update "Getting Started" documents for Windows users (to direct them
> to use docker or cloud)
> 
> Regards,
> Yuki
> 
> --
> *: 
> https://mail-archives.apache.org/mod_mbox/cassandra-dev/202007.mbox/%3CCAGM0Up_3GoPucCP-U18L1akzBXS1eJoKbui997%3DajcCfKJQdng%40mail.gmail.com%3E
> 
> -
> 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: naming development branches consistently

[Aleksey Yeshchenko]

Last thing I want is to bikeshed, but seems like ‘main’ is what’s being adopted 
by GitHub, so we might as well rename all ‘master’ and ’trunk’ branches to that.

> On 24 Aug 2020, at 17:22, Joshua McKenzie  wrote:
> 
> Ah! Totally didn't even think of that. Good point.
> 
> On Mon, Aug 24, 2020 at 12:12 PM Brandon Williams  wrote:
> 
>> With the current social climate I thought removing the master
>> reference rather than proliferating it would be better.
>> 
>> On Mon, Aug 24, 2020 at 11:07 AM Joshua McKenzie 
>> wrote:
>>> 
>>> Why not rename "trunk" to "master" in C*?   =D
>>> 
>>> On Mon, Aug 24, 2020 at 11:17 AM Brandon Williams 
>> wrote:
>>> 
 Hello,
 
 Currently in the cassandra repo our development branch is named
 'trunk', but this is not consistently used in other repos, such as
 cassandra-dtest, -builds, -website, and probably others, which use
 'master' instead.  I propose we rename all of those to 'trunk' to
 match.
 
 Kind Regards,
 Brandon
 
 -
 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: Problem in updating schema in Cassandra 3.11.4

[Aleksey Yeshchenko]

I’m reasonably certain that this is one of the things that I fixed in 4.0. It’d 
be too invasive a change for 3.11, unfortunately.

> On 1 Sep 2020, at 16:52, Benjamin Lerer  wrote:
> 
> Hi,
> 
> Could you precise what you mean by " will only validate the schema while
> changing in memory, and will not validate before flush to disk.". It is
> unclear to me of which validation you are talking about.
> 
> 
> 
> 
> 
> On Tue, Sep 1, 2020 at 1:44 PM Weiliang Zhang <394693...@qq.com> wrote:
> 
>> Does anyone has any ideas?
>> 
>> On 2020/08/31 10:07:30, weiliang zhang<394693...@qq.com> wrote:
>>> Hi everyone, I found that cassandra will first flush new schema to disk
>> and then change in memory while updating schema in Cassandra3.11.4
>> (SchemaKeyspace.java:1378) .
>>> But it seems that cassandra will only validate the schema while changing
>> in memory, and will not validate before flush to disk.
>>> I don't know why not validate before flushing to disk ? Some request
>> will succeed in updating schema to disk and fail to update schema in
>> memory, which will make the schema in disk and schema in memory are not
>> consistent.
>>> 
>>> -
>>> 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: [DISCUSS] Change style guide to recommend use of @Override

[Aleksey Yeshchenko]

+1. Some of us have already adopted this change some time ago, but it’d be nice 
to make it official for everybody.

> On 1 Sep 2020, at 19:27, David Capwell  wrote:
> 
> Currently our style guide recommends to avoid using @Override and updates
> intellij's code style to exclude it by default; I would like to propose we
> change this recommendation to use it and to update intellij's style to
> include it by default.
> 
> @Override is used by javac to enforce that a method is in fact overriding
> from an abstract class or an interface and if this stops being true (such
> as a refactor happens) then a compiler error is thrown; when we default to
> excluding, it makes it harder to detect that a refactor catches all
> implementations and can lead to subtle and hard to track down bugs.
> 
> This proposal is for new code and would not be to go rewrite all code at
> once, but would recommend new code adopt this style, and to pull old code
> forward which is related to changes being made (similar to our stance on
> imports).
> 
> If people are ok with this, I will file a JIRA, update the docs, and
> update intellij's formatting.
> 
> Thanks for your time!


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Accept the Harry donation

[Aleksey Yeshchenko]

+1

> On 16 Sep 2020, at 16:09, Sumanth Pasupuleti 
>  wrote:
> 
> +1 (non-binding)
> 
> On Wed, Sep 16, 2020 at 7:41 AM Jon Meredith  wrote:
> 
>> +1 (non-binding)
>> 
>> On Wed, Sep 16, 2020 at 8:28 AM David Capwell
>>  wrote:
>>> 
>>> +1
>>> 
>>> Sent from my iPhone
>>> 
 On Sep 16, 2020, at 6:34 AM, Brandon Williams 
>> wrote:
 
 +1
 
> On Wed, Sep 16, 2020, 4:45 AM Mick Semb Wever  wrote:
> 
> This vote is about officially accepting the Harry donation from Alex
>> Petrov
> and Benedict Elliott Smith, that was worked on in CASSANDRA-15348.
> 
> The Incubator IP Clearance has been filled out at
> http://incubator.apache.org/ip-clearance/apache-cassandra-harry.html
> 
> This vote is a required part of the IP Clearance process. It follows
>> the
> same voting rules as releases, i.e. from the PMC a minimum of three
>> +1s and
> no -1s.
> 
> Please cast your votes:
>  [ ] +1 Accept the contribution into Cassandra
>  [ ] -1 Do not
> 
>>> 
>>> -
>>> 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 3.0.24

[Aleksey Yeshchenko]

+1

> On 29 Jan 2021, at 14:31, Ekaterina Dimitrova  wrote:
> 
> +1(nb)
> 
> On Fri, 29 Jan 2021 at 8:21, Oleksandr Petrov 
> wrote:
> 
>>> Proposing the test build of Cassandra 4.0-beta4 for release.
>> 
>> Correction: test build of 3.0.24. The rest looks right.
>> 
>> On Fri, Jan 29, 2021 at 1:48 PM Oleksandr Petrov <
>> oleksandr.pet...@gmail.com>
>> wrote:
>> 
>>> Proposing the test build of Cassandra 4.0-beta4 for release.
>>> 
>>> sha1: 6748ecd63cae047b5b0e8c3165088252954e9d5f
>>> Git:
>>> 
>>> 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.24-tentative
>>> Maven Artifacts:
>>> 
>>> 
>> https://repository.apache.org/content/repositories/orgapachecassandra-1229/org/apache/cassandra/cassandra-all/3.0.24/
>>> 
>>> 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.24/
>>> 
>>> 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.24-tentative
>>> [2]: NEWS.txt:
>>> 
>>> 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.24-tentative
>>> 
>> 
>> 
>> --
>> alex p
>> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Hints replay incompatible between 2.x and 3.x

[Aleksey Yeshchenko]

It doesn’t work between any two majors (1.2 and 2.0, 2.0 and 2.1, 2.1 and 3.0).

The reason is that hint delivery doesn’t proceed between two nodes unless they 
have the same schema version,
and in every recent major release we made changes that made schema calculation 
differ even without any DDL
statements going on.

There might be an argument for relaxing that restriction, and/or for making 
schema versioning more stable, but we are where we are right now.

—
AY

On 30 August 2017 at 18:06:00, Jason Brown (jasedbr...@gmail.com) wrote:

Hi Andrew,  

This question is best for the user@ list, included here.  

Thanks,  

-Jason  

On Wed, Aug 30, 2017 at 10:00 AM, Andrew Whang   
wrote:  

> In evaluating 3.x, we found that hints are unable to be replayed between  
> 2.x and 3.x nodes. This introduces a risk during the upgrade path for some  
> of our write-heavy clusters - nodes will accumulate upwards of 1TB of hints  
> if a node goes/remains down for <1hr.  
>  
> Any suggestions to mitigate this issue?  
>  

Re: Compact Storage and SuperColumn Tables in 4.0/trunk

[Aleksey Yeshchenko]

4.0 should also fail startup (very early) if it still sees any non-migrated 
tables, probably.

—
AY

On 19 September 2017 at 18:35:11, J. D. Jordan (jeremiah.jor...@gmail.com) 
wrote:

Thanks for the clarification. +1 for adding a "DROP COMPACT STORAGE" option in 
3.x and then not allowing it to be specified in 4.0.  


On Sep 19, 2017, at 1:27 PM, Alex P  wrote:  

>> If we provide a way to drop the flag, but still access the data, I think 
>> that is fine and perfectly reasonable. If the proposal here is that users 
>> who have data in COMPACT STORAGE tables have no way to upgrade to 4.0 and 
>> still access that data without exporting it to a brand new table, then I am 
>> against it. Can you clarify which thing is being proposed? It is not clear 
>> to me.  
>  
>  
> A bit of details on how compact storage and all thrift tables are 
> implemented:  
>  
> When a table is created through thrift or with COMPACT STORAGE flag, it has a 
> `value` column, which is invisible when doing any CQL queries and only seen 
> through Thrift.  
> With SuperColumn families, internally (on the storage level) have a partition 
> key, clustering and a value column that has a type of `map<>`. Thrift exposes 
> it as a “normal” super column family. CQL, however, does not expose this 
> `map` column. Instead, it translates the key of the map into the second 
> clustering and a map value as a regular column.  
>  
> All of this requires quite some special-casing everywhere across the CQL 
> layer, in order to hide/show and translate the columns depending on whether 
> the table is dense, super and so on.  
>  
>  
>  
> For more details you can take a look at 8099 or 12373.  
>  
> In short: dropping a COMPACT STORAGE flag means that your tables will be 
> accessible and their internal representation (e.g. hidden value column) will 
> be exposed as if it was a normal column. No data will be lost, no data will 
> be inaccessible. You can take a look at the details of CASSANDRA-10857 if you 
> want more details.  
>  
> As regards SuperColumn families, my proposal is to have a 100% support in 
> 3.0/3.11 (LWTs, counters, all sorts of queries, exactly like they were 
> accessible through CQL in 2.2).  
>  
> There will be a clear upgrade path, but I suggest that the DROP COMPACT 
> STORAGE has to be in 3.x only.  
>  
> 4.x will still make the same data available, but expose the whole internal 
> CQL structure, together with a usually “hidden" compact value column, without 
> any legacy special-casing.  
>  
>  
>  
>  
>  
>  
>  
>> On 19 Sep 2017, at 17:23, Jeremiah D Jordan  
>> wrote:  
>>  
>> I think that all the work to support Compact Storage tables from CQL seems 
>> like wasted effort if we are going to tell people “just kidding, you have to 
>> migrate all your data”. I do not think supporting “COMPACT STORAGE” as a 
>> table option matters one way or the other. But I do think being able to read 
>> the data that was in a table created that way is something we need to have a 
>> path forward for.  
>>  
>>> since thrift is not supported on trunk/4.0, it makes it much less appealing 
>>> or even necessary  
>>  
>> I think that the fact thrift is not supported on trunk/4.0 makes accessing 
>> said data from CQL *MORE* necessary and appealing.  
>>  
>>> possibility drop a Compact Storage flag and expose them as “normal" tables, 
>>> there was an idea of removing the Compact Tables from 4.x altogether.  
>>  
>> If we provide a way to drop the flag, but still access the data, I think 
>> that is fine and perfectly reasonable. If the proposal here is that users 
>> who have data in COMPACT STORAGE tables have no way to upgrade to 4.0 and 
>> still access that data without exporting it to a brand new table, then I am 
>> against it. Can you clarify which thing is being proposed? It is not clear 
>> to me.  
>>  
>> -Jeremiah  
>>  
>>  
>>> On Sep 19, 2017, at 7:10 AM, Oleksandr Petrov >> > wrote:  
>>>  
>>> As you may know, SuperColumn Tables did not work in 3.x the way they worked 
>>> in 2.x. In order to provide everyone with a reasonable upgrade path, we've 
>>> been working on CASSANDRA-12373[1], that brings in support for SuperColumn 
>>> tables as close to 2.x as possible. The patch is planned to land 
>>> cassandra-3.0 and cassandra-3.11 branches only, since the patch for trunk 
>>> will require even more work and, since thrift is not supported on 
>>> trunk/4.0, it makes it much less appealing or even necessary. The idea 
>>> behind the support for SuperColumns was always only to allow people to 
>>> smoothly migrate off them in 3.0/3.11 world, not to have them as a primary 
>>> feature.  
>>>  
>>> SuperColumns are not the only type of Compact Table, there are more. After 
>>> CASSANDRA-8099[2], Compact Tables are special-cased and have special schema 
>>> layout with some columns hidden from CQL, that allows them to be used from 
>>> Thrift. But, except for the fact they’

Re: State of Materialized Views

[Aleksey Yeshchenko]

It’s the only remaining one on my radar. But we should be good next week - so 
long as nothing else pops up, and I’m not missing any other JIRAs.

—
AY

On 22 September 2017 at 19:18:12, Michael Shuler (mich...@pbandjelly.org) wrote:

I asked the same question on IRC a couple days ago and Aleksey asked if  
I could hold for CASSANDRA-13595.  

--  
Kind regards,  
Michael  

On 09/22/2017 01:02 PM, Ben Bromhead wrote:  
> Just saw that https://issues.apache.org/jira/browse/CASSANDRA-11500 got  
> commited 4 days ago, awesome stuff and a huge thank you to everyone who  
> worked on it!  
>  
> Looking forward to what happens in  
> https://issues.apache.org/jira/browse/CASSANDRA-13826 :)  
>  
> I don't know if we are waiting on anything other than  
> https://issues.apache.org/jira/browse/CASSANDRA-13808 for 3.11.1 ?  
>  
> On Tue, 25 Jul 2017 at 04:58 Josh McKenzie  wrote:  
>  
>> Status of above is on our collective radars. As always, interleaving  
>> reviews with other work is a challenge.  
>>  
>> On Mon, Jul 24, 2017 at 7:05 PM, Nate McCall  wrote:  
>>  
  
 We're working on the following MV-related issues in the 4.0 time-frame:  
 CASSANDRA-13162  
 CASSANDRA-13547  
>>> Patch Available  
>>>  
 CASSANDRA-13127  
>>> Patch Available  
>>>  
 CASSANDRA-13409  
>>> Patch Available  
>>>  
 CASSANDRA-12952  
>>> Patch Available  
>>>  
 CASSANDRA-13069  
 CASSANDRA-12888  
  
>>>  
>>> Josh - want to make sure folks are not duplicating effort here, is the  
>>> status of the above on your radar? Regardless, I appreciate the  
>>> communication. Thanks for that!  
>>>  
>>> -  
>>> 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: Expected release date for 3.11.1?

[Aleksey Yeshchenko]

FWIW, none of the remaining issues are strictly speaking regressions from 
previous versions.

So if we felt strongly about starting the vote right now, I wouldn’t object, 
and would vote +1 - there is a lot of fixes accumulated there already.

But all I need is a few days here, assuming review is done quickly, and we’ll 
be able to include some reasonably major fixes to long-lasting issues for the 
price of a few days’s delay (admittedly only CASSANDRA-13595 really qualifies).

I’m aiming for end of this week/mid next week completion of the remaining 
tickets. If we can wait that long, great. If we feel an urge to go ahead now, 
then it’ll have to be 3.0.16/3.11.2 for fully working short read protection.

—
AY

On 28 September 2017 at 00:04:13, Michael Shuler (mich...@pbandjelly.org) wrote:

On 09/27/2017 02:40 PM, Vincent Lee wrote:  
> Anyone has an approximate date when 3.11.1 will be released?  
> Interested to get fix for CASSANDRA-13752  

The issues currently in progress for 3.11.1 are:  

CASSANDRA-13595 Implement short read protection on partition boundaries  
CASSANDRA-13808 Integer overflows with Amazon Elastic File System (EFS)  
CASSANDRA-13911 IllegalStateException thrown by UPI.Serializer.hasNext()  
for some SELECT queries  
CASSANDRA-13913 Be more optimistic when fetching more rows for SRP  

After these are committed, I'll get the release rolled up. The devs  
working on these issues project mid next week completion (maybe sooner -  
now you're on the hook, Aleksey :). The above also affect 3.0.15, so  
we'll also get that version released.  

If you're having problems now and want the latest artifacts that contain  
CASSANDRA-13752 already, you can grab those from:  

https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-3.11-artifacts/ 
 

If you want to build your own packages, the README.md on the -builds  
repo has the steps:  

https://github.com/apache/cassandra-builds  

--  
Kind regards,  
Michael  

-  
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org  
For additional commands, e-mail: dev-h...@cassandra.apache.org  

Re: [VOTE] Release Apache Cassandra 2.1.19

[Aleksey Yeshchenko]

+1

—
AY

On 28 September 2017 at 19:12:19, Michael Shuler (mich...@pbandjelly.org) wrote:

I propose the following artifacts for release as 2.1.19.  

sha1: 428eaa3e37cab7227c81fdf124d29dfc1db4257c  
Git:  
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.19-tentative
  
Artifacts:  
https://repository.apache.org/content/repositories/orgapachecassandra-1148/org/apache/cassandra/apache-cassandra/2.1.19/
  
Staging repository:  
https://repository.apache.org/content/repositories/orgapachecassandra-1148/  

The Debian and RPM packages are available here:  
http://people.apache.org/~mshuler  

The vote will be open for 72 hours (longer if needed).  

[1]: (CHANGES.txt) https://goo.gl/1sZLdP (also RPM file ownership fix)  
[2]: (NEWS.txt) https://goo.gl/YKEuRc  

-  
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org  
For additional commands, e-mail: dev-h...@cassandra.apache.org  

Re: [VOTE] Release Apache Cassandra 2.2.11

[Aleksey Yeshchenko]

+1

—
AY

On 28 September 2017 at 19:41:13, Michael Shuler (mich...@pbandjelly.org) wrote:

I propose the following artifacts for release as 2.2.11.  

sha1: c510e001481637e1f74d9ad176f8dc3ab7ebd1e3  
Git:  
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.11-tentative
  
Artifacts:  
https://repository.apache.org/content/repositories/orgapachecassandra-1149/org/apache/cassandra/apache-cassandra/2.2.11/
  
Staging repository:  
https://repository.apache.org/content/repositories/orgapachecassandra-1149/  

The Debian and RPM packages are available here:  
http://people.apache.org/~mshuler  

The vote will be open for 72 hours (longer if needed).  

[1]: (CHANGES.txt) https://goo.gl/qTG7xU (also RPM file ownership fix)  
[2]: (NEWS.txt) https://goo.gl/ggdkLH  

-  
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org  
For additional commands, e-mail: dev-h...@cassandra.apache.org  

Re: Expected release date for 3.11.1?

[Aleksey Yeshchenko]

Status update:

CASSANDRA-13595 is now fixed,
CASSANDRA-13808 is now fixed,
CASSANDRA-13911 is now fixed.

This leaves CASSANDRA-13913, but I don’t think we should block the release on 
it.

Unless someone has anything else on their radar, I believe we can proceed with 
the vote now.

P.S. Also cleaned up CHANGES.txt; please be a bit more careful when merging it.

—
AY

On 28 September 2017 at 19:54:42, Nate McCall (zznat...@gmail.com) wrote:

Agree on waiting for SRP. And in general having the patience to put out  
artifacts in which we have higher confidence.  

Thanks for the effort Alexi.  

On Sep 29, 2017 5:29 AM, "Michael Shuler"  wrote:  

> I'm happy to include these for the quality. Let's draw the line in the  
> sand for these remaining tickets, so we can get 3.0.15/3.11.1 out. A few  
> more days is not a problem.  
>  
> I appreciate the update!  
>  
> --  
> Michael  
>  
> On 09/28/2017 10:50 AM, Aleksey Yeshchenko wrote:  
> > FWIW, none of the remaining issues are strictly speaking regressions  
> from previous versions.  
> >  
> > So if we felt strongly about starting the vote right now, I wouldn’t  
> object, and would vote +1 - there is a lot of fixes accumulated there  
> already.  
> >  
> > But all I need is a few days here, assuming review is done quickly, and  
> we’ll be able to include some reasonably major fixes to long-lasting issues  
> for the price of a few days’s delay (admittedly only CASSANDRA-13595 really  
> qualifies).  
> >  
> > I’m aiming for end of this week/mid next week completion of the  
> remaining tickets. If we can wait that long, great. If we feel an urge to  
> go ahead now, then it’ll have to be 3.0.16/3.11.2 for fully working short  
> read protection.  
> >  
> > —  
> > AY  
> >  
> > On 28 September 2017 at 00:04:13, Michael Shuler (mich...@pbandjelly.org)  
> wrote:  
> >  
> > On 09/27/2017 02:40 PM, Vincent Lee wrote:  
> >> Anyone has an approximate date when 3.11.1 will be released?  
> >> Interested to get fix for CASSANDRA-13752  
> >  
> > The issues currently in progress for 3.11.1 are:  
> >  
> > CASSANDRA-13595 Implement short read protection on partition  
> boundaries  
> > CASSANDRA-13808 Integer overflows with Amazon Elastic File System  
> (EFS)  
> > CASSANDRA-13911 IllegalStateException thrown by  
> UPI.Serializer.hasNext()  
> > for some SELECT queries  
> > CASSANDRA-13913 Be more optimistic when fetching more rows for SRP  
> >  
> > After these are committed, I'll get the release rolled up. The devs  
> > working on these issues project mid next week completion (maybe sooner -  
> > now you're on the hook, Aleksey :). The above also affect 3.0.15, so  
> > we'll also get that version released.  
> >  
> > If you're having problems now and want the latest artifacts that contain  
> > CASSANDRA-13752 already, you can grab those from:  
> >  
> > https://builds.apache.org/view/A-D/view/Cassandra/job/  
> Cassandra-3.11-artifacts/  
> >  
> > If you want to build your own packages, the README.md on the -builds  
> > repo has the steps:  
> >  
> > https://github.com/apache/cassandra-builds  
> >  
> > --  
> > Kind regards,  
> > Michael  
> >  
> > -  
> > 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: Proposal to retroactively mark materialized views experimental

[Aleksey Yeshchenko]

The idea is to check the flag in CreateViewStatement, so creation of new MVs 
doesn’t succeed without that flag flipped.

Obviously, just disabling existing MVs working in a minor would be silly.

As for the warning - yes, that should also be emitted. Unconditionally.

—
AY

On 2 October 2017 at 18:18:52, Jeremiah D Jordan (jeremiah.jor...@gmail.com) 
wrote:

These things are live on clusters right now, and I would not want someone to 
upgrade their cluster to a new *patch* release and suddenly something that may 
have been working for them now does not function. Anyway, we need to be careful 
about how this gets put into practice if we are going to do it retroactively. 

Re: [VOTE] Release Apache Cassandra 3.0.15

[Aleksey Yeshchenko]

+1

—
AY

On 2 October 2017 at 18:18:26, Michael Shuler (mich...@pbandjelly.org) wrote:

I propose the following artifacts for release as 3.0.15.  

sha1: b32a9e6452c78e6ad08e371314bf1ab7492d0773  
Git:  
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.15-tentative
  
Artifacts:  
https://repository.apache.org/content/repositories/orgapachecassandra-1150/org/apache/cassandra/apache-cassandra/3.0.15/
  
Staging repository:  
https://repository.apache.org/content/repositories/orgapachecassandra-1150/  

The Debian packages are available here: http://people.apache.org/~mshuler  

The vote will be open for 72 hours (longer if needed).  

[1]: (CHANGES.txt) https://goo.gl/RyuPpw  
[2]: (NEWS.txt) https://goo.gl/qxwUti  

-  
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.1

[Aleksey Yeshchenko]

+1

—
AY

On 2 October 2017 at 18:58:57, Michael Shuler (mich...@pbandjelly.org) wrote:

I propose the following artifacts for release as 3.11.1.  

sha1: 983c72a84ab6628e09a78ead9e20a0c323a005af  
Git:  
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.1-tentative
  
Artifacts:  
https://repository.apache.org/content/repositories/orgapachecassandra-1151/org/apache/cassandra/apache-cassandra/3.11.1/
  
Staging repository:  
https://repository.apache.org/content/repositories/orgapachecassandra-1151/  

The Debian packages are available here: http://people.apache.org/~mshuler  

The vote will be open for 72 hours (longer if needed).  

[1]: (CHANGES.txt) https://goo.gl/dZCRk8  
[2]: (NEWS.txt) https://goo.gl/rh24MX  

-  
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.1

[Aleksey Yeshchenko]

Thomas,

I would maybe agree with waiting for a while because of it, if we had a proper 
fix at least under review - or in progress by someone.

But this is not a regression, and there’s been a lot of fixes accumulated and 
not released yet. Arguable worse to hold them back :\

—
AY

On 2 October 2017 at 20:54:38, Steinmaurer, Thomas 
(thomas.steinmau...@dynatrace.com) wrote:

Jeff,  

even if it is not a strict regression, this currently forces us to do a rolling 
restart every ~ 72hrs to be on the safe-side with -Xmx8G. Luckily this is just 
a loadtest environment. We don't have 3.11 in production yet.  

I can offer to immediately deploy a snapshot build into our loadtest 
environment, in case this issue gets attention and a fix needs verification at 
constant load.  

Thanks,  
Thomas  

-Original Message-  
From: Jeff Jirsa [mailto:jji...@gmail.com]  
Sent: Montag, 02. Oktober 2017 20:04  
To: Cassandra DEV   
Subject: Re: [VOTE] Release Apache Cassandra 3.11.1  

+1  

( Somewhat concerned that  
https://issues.apache.org/jira/browse/CASSANDRA-13754 may not be fixed, but 
it's not a strict regression ? )  



On Mon, Oct 2, 2017 at 10:58 AM, Michael Shuler   
wrote:  

> I propose the following artifacts for release as 3.11.1.  
>  
> sha1: 983c72a84ab6628e09a78ead9e20a0c323a005af  
> Git:  
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=  
> shortlog;h=refs/tags/3.11.1-tentative  
> Artifacts:  
> https://repository.apache.org/content/repositories/  
> orgapachecassandra-1151/org/apache/cassandra/apache-cassandra/3.11.1/  
> Staging repository:  
> https://repository.apache.org/content/repositories/  
> orgapachecassandra-1151/  
>  
> The Debian packages are available here:  
> http://people.apache.org/~mshuler  
>  
> The vote will be open for 72 hours (longer if needed).  
>  
> [1]: (CHANGES.txt) https://goo.gl/dZCRk8  
> [2]: (NEWS.txt) https://goo.gl/rh24MX  
>  
> -  
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org  
> For additional commands, e-mail: dev-h...@cassandra.apache.org  
>  
>  
The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a 
company registered in Linz whose registered office is at 4040 Linz, Austria, 
Freistädterstraße 313  

-  
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org  
For additional commands, e-mail: dev-h...@cassandra.apache.org  

Re: Proposal to retroactively mark materialized views experimental

[Aleksey Yeshchenko]

need it:  
> in  
> > >> the development process.  
> > >>  
> > >> How does emitting a native protocol warning reduce visibility during  
> the  
> > >> development process? If you run CREATE MV and cqlsh then prints out a  
> > >> giant warning statement about how it is an experimental feature I  
> think  
> > >> that is pretty visible during development?  
> > >>  
> > >> I guess I can see just blocking new ones without a flag set, but we  
> need  
> > >> to be careful here. We need to make sure we don’t cause a problem for  
> > >> someone that is using them currently, even with all the edge cases  
> > issues  
> > >> they have now.  
> > >>  
> > >> -Jeremiah  
> > >>  
> > >>  
> > >>> On Oct 2, 2017, at 2:01 PM, Blake Eggleston   
> > >> wrote:  
> > >>>  
> > >>> Yeah, I'm not proposing that we disable MVs in existing clusters.  
> > >>>  
> > >>>  
> > >>> On October 2, 2017 at 10:58:11 AM, Aleksey Yeshchenko (  
> > alek...@apple.com)  
> > >> wrote:  
> > >>>  
> > >>> The idea is to check the flag in CreateViewStatement, so creation of  
> > new  
> > >> MVs doesn’t succeed without that flag flipped.  
> > >>>  
> > >>> Obviously, just disabling existing MVs working in a minor would be  
> > silly.  
> > >>>  
> > >>> As for the warning - yes, that should also be emitted.  
> Unconditionally.  
> > >>>  
> > >>> —  
> > >>> AY  
> > >>>  
> > >>> On 2 October 2017 at 18:18:52, Jeremiah D Jordan (  
> > >> jeremiah.jor...@gmail.com) wrote:  
> > >>>  
> > >>> These things are live on clusters right now, and I would not want  
> > >> someone to upgrade their cluster to a new *patch* release and suddenly  
> > >> something that may have been working for them now does not function.  
> > >> Anyway, we need to be careful about how this gets put into practice if  
> > we  
> > >> are going to do it retroactively.  
> > >>  
> > >>  
> > >> -  
> > >> 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: Proposal to retroactively mark materialized views experimental

[Aleksey Yeshchenko]

Yep. And that would be nice to have in addition to the opt-in flag in the yaml 
for the operators that’s stricter than a warning.

—
AY

On 2 October 2017 at 22:21:33, Jeremiah D Jordan (jerem...@datastax.com) wrote:

We are not saying to just put something in logs, we are talking about the warn 
actually showing up in cqlsh. 
When you issue a native protocol warn cqlsh will print it out on the console in 
front of you in the results of the query. 

Re: Proposal to retroactively mark materialized views experimental

[Aleksey Yeshchenko]

There are a couple compromise options here:

a) Introduce the flag (enalbe_experimental_features, or maybe one per 
experimental feature), set it to ‘false’ in the yaml, but have the default be 
‘true’. So that if you are upgrading from a previous minor to the next without 
updating the yaml, you notice nothing.

b) Introduce the flag in the minor, and set it to ‘true’ in the yaml in 3.0 and 
3.11, but to ‘false’ in 4.0. So the operators and in general people who know 
better can still disable it with one flip, but nobody would be affected by it 
in a minor otherwise.

B might be more correct, and I’m okay with it, although I do feel that we are 
behaving irresponsibly as developers by allowing MV creation by default in 
their current state and that it’s better to correct a mistake late than later.

—
AY

On 3 October 2017 at 10:27:58, Sylvain Lebresne (sylv...@datastax.com) wrote:

Just one more data point, but I personally don't feel that disabling 
new MV creation (or new SAS index creation for that matter) by default 
_in a patch release_ is terribly nice.