Re: CCM and CASSANDRA_USE_JDK11

Hi, There is definitely a mismatch between how the full range of dtests work and the direction CCM is going in and we have some difficulty getting those to match. I fully empathize with several of those CI systems not being publicly visible/accessible, and the behavior of upgrade paths being

Re: [DISCUSS] ccm as a subproject

Hi, Strong +1 as well. It's a pretty critical dependency in the path of testing and committing changes. Supporting integration points for alternative distributions of Cassandra is something I think we should generally be supportive as it's generally an opportunity to make things more modular

Re: discuss: add to_human_size function

Hi, I think it’s a good quality of life improvement, but I am someone who believes in a rich set of built-in functions being a good thing. A format function is a bit more scope and kind of orthogonal. It would still be good to have shorthand functions for things like size. Ariel On Tue, Apr

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

Hi, If there is a faster/better way to replace a node why not have Cassandra support that natively without the sidecar so people who aren’t running the sidecar can benefit? Copying files over a network shouldn’t be slow in C* and it would also already have all the connectivity issues solved.

Re: Harry in-tree (Forked from "Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?")

拾 Thanks for your work on this. Excited to have an easier way to write tests that leverage schema and data that also covers more. Ariel On Sat, Dec 23, 2023, at 9:17 AM, Alex Petrov wrote: > Thanks everyone, Harry is now in tree! Of course, that's just a small > milestone, hope it'll prove as

Re: [DISCUSS] CEP-39: Cost Based Optimizer

Hi, I am burying the lede, but it's important to keep an eye on runtime-adaptive vs planning time optimization as the cost/benefits vary greatly between the two and runtime adaptive can be a game changer. Basically CBO optimizes for query efficiency and startup time at the expense of not

Re: Future direction for the row cache and OHC implementation

Hi, Thanks for the generous offer. Before you do that can you give me a chance to add back support for Caffeine for the row cache so you can test the option of switching back to an on-heap row cache? Ariel On Thu, Dec 14, 2023, at 9:28 PM, Jon Haddad wrote: > I think we should probably figure

Re: Future direction for the row cache and OHC implementation

gt;>> So, unless it is being widely used by someone else outside of the >>> community (which it doesn't seem to be), from a maintenance and >>> integration testing perspective I think it would be better to keep the >>> ohc in-tree, so we will be aware of any issues imme

Re: Future direction for the row cache and OHC implementation

Hi, To add some additional context. The row cache is disabled by default and it is already pluggable, but there isn’t a Caffeine implementation present. I think one used to exist and could be resurrected. I personally also think that people should be able to scratch their own itch row cache

Future direction for the row cache and OHC implementation

Hi, Now seems like a good time to discuss the future direction of the row cache and its only implementation OHC (https://github.com/snazy/ohc). OHC is currently unmaintained and we don’t have the ability to release maven artifacts for it or commit to the original repo. I have reached out to

Re: [DISCUSS] CEP-36: A Configurable ChannelProxy to alias external storage locations

Hi, Support for multiple storage backends including remote storage backends is a pretty high value piece of functionality. I am happy to see there is interest in that. I think that `ChannelProxyFactory` as an integration point is going to quickly turn into a dead end as we get into really

Re: [DISCUSS] Lift MessagingService.minimum_version to 40 in trunk

Hi, I am pretty strongly in favor just to keep the amount of code kept around for serialization/deserialization and caching serialized sizes for different versions under control. 5.0 will have changes necessitating using another version so it will be adding to the clutter. Ariel On Mon, Mar

Re: Welcome Patrick McFadin as Cassandra Committer

Welcome Patrick! Thank you for your years of contributions to the community. On Thu, Feb 2, 2023, at 12:58 PM, Benjamin Lerer wrote: > The PMC members are pleased to announce that Patrick McFadin has accepted > the invitation to become committer today. > > Thanks a lot, Patrick, for everything

Re: [VOTE] CEP-21 Transactional Cluster Metadata

+1 On Mon, Feb 6, 2023, at 11:15 AM, Sam Tunnicliffe wrote: > Hi everyone, > > I would like to start a vote on this CEP. > > Proposal: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata > > Discussion: >

Re: CASSANDRA-14482

Hi, I am +1 since it's an additional compressor and not the default. Ariel On Fri, Feb 15, 2019, at 11:41 AM, Dinesh Joshi wrote: > Hey folks, > > Just wanted to get a pulse on whether we can proceed with ZStd support. > The consensus on the ticket was that it’s a very valuable addition >

Re: cqlsh tests and Python 3

Hi, Do you mean Python 2/3 compatibility? This has been discussed earlier and I think that being compatible with both is an easier sell. Ariel > On Feb 11, 2019, at 1:24 PM, dinesh.jo...@yahoo.com.INVALID > wrote: > > Hey all, > We've gotten the cqlsh tests running in the Cassandra repo

Re: [VOTE] Release Apache Cassandra 3.11.4

73-L174> > > Let me know if this looks good to you, I will send a patch to > cassandra-dtest > > > > Thanks, > Vinay Chella > > > On Wed, Feb 6, 2019 at 8:07 PM Vinay Chella wrote: > > > Hi Ariel, > > > > Sure, I am volunteering t

Re: [VOTE] Release Apache Cassandra 3.11.4

Hi, It fails consistently. I don't know why the data is not evenly distributed. Can someone volunteer to debug this failing test to make sure there isn't an issue with bootstrap in 3.11? https://circleci.com/gh/aweisberg/cassandra/2593 Thanks, Ariel On Wed, Feb 6, 2019, at 3:11 PM, Ariel

Re: [VOTE] Release Apache Cassandra 3.11.4

Hi, -0 bootstrap_upgrade_test.py test_simple_bootstrap_mixed_versions fails because it doesn't see the expected on disk size within 30% of the expected value. It's bootstrapping a new version node and runs cleanup on the existing node. If the data were evenly distributed the on disk size

Re: [VOTE] Release Apache Cassandra 3.0.18

Hi, +1 Upgrade test look OK. There are failures I also found against 2.2 plus some other test bugs. Nothing that looks like a product bug. https://circleci.com/gh/aweisberg/cassandra/2589 Ariel On Wed, Feb 6, 2019, at 5:02 AM, Marcus Eriksson wrote: > +1 > > Den ons 6 feb. 2019 kl 10:53

Re: [VOTE] Release Apache Cassandra 2.2.14

Hi, +1 Upgrade tests: https://circleci.com/gh/aweisberg/cassandra/2587 Known issue https://issues.apache.org/jira/browse/CASSANDRA-14155 which is not a blocker There is a test failure on a thrift connection not being open. Might be test bug. If it's a product bug it's probably not that

Re: [VOTE] Release Apache Cassandra 2.2.14

Hi, Can we also run the upgrade tests? We should do that as part of the release process. I can do that tomorrow. Ariel On Tue, Feb 5, 2019, at 1:11 PM, Joseph Lynch wrote: > 2.2.14-tentative unit and dtest run: > https://circleci.com/gh/jolynch/cassandra/tree/2.2.14-tentative > > unit tests:

Re: Implementing an Abstract Replication Strategy

Hi, Cassandra expects a replication strategy to accept a description of a consistent hash ring and then use that description to determine what ranges on the consistent hash ring each node replicates. If you implement the API those operations should all just work. I'm not sure what the

Re: Git Repo Migration

+1 On Fri, Jan 4, 2019, at 5:49 AM, Sam Tunnicliffe wrote: > As per the announcement on 7th December 2018[1], ASF infra are planning > to shutdown the service behind git-wip-us.apache.org and migrate all > existing repos to gitbox.apache.org > > There are further details in the original mail,

Re: [VOTE] Change Jira Workflow

+1 On Mon, Dec 17, 2018, at 10:19 AM, Benedict Elliott Smith wrote: > I propose these changes > * > > to the Jira Workflow for the project. The vote will be open for 72 > hours**. > > I am, of course, +1. > > *

Re: Revisit the proposal to use github PR

l, unless there's some > technique I and perhaps others are unaware of. > > On Thu, Dec 13, 2018 at 9:47 AM Ariel Weisberg wrote: > > > Hi, > > > > I'm not clear on what github makes worse. It preserves more history then > > the JIRA approach. When people invitably

Re: Revisit the proposal to use github PR

Hi, I'm not clear on what github makes worse. It preserves more history then the JIRA approach. When people invitably force push their branches you can't tell from the link to a branch on JIRA. Github preserves the comments and force push history so you know what version of the code each

Re: JIRA Workflow Proposals

Hi, Updating to reflect the new options for 1. 2, 3, and 4 remain unchanged. 1. E, D, C, B, A 2. B, C, A 3. A 4. -.5 Ariel On Tue, Dec 11, 2018, at 10:55 AM, Ariel Weisberg wrote: > Hi, > > Sorry I was just slow on the uptake as to what auto-populate meant RE #2. > &g

Re: JIRA Workflow Proposals

that harmful either. Ariel On Mon, Dec 10, 2018, at 8:51 PM, 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

Re: JIRA Workflow Proposals

ng view. > > My votes are: > 1: +1 > 2: B,C,A > 3: A > 4: +0.5 > > > For tracking, the new consensus from the prior vote is: > 1: A (+10) > 2: +9 -0.1 > 3: +10 > 4: +6 -2 (=+4) > 5: +2; a lot of meh. > 6: +9 > > > > > On 7 Dec 2018, at 17:

Re: JIRA Workflow Proposals

t; > On 7 Dec 2018, at 17:52, Ariel Weisberg wrote: > > > > Hi, > > > > Late but. > > No harm in them continuing to roll in, I’m just cognisant of needing to > annoy everyone with a second poll, so no point perpetuating it past a > likely unassailable conse

Re: JIRA Workflow Proposals

Hi, Late but. 1. A 2. +1 3. +1 4. -1 5. -0 6. +1 RE 4, I think blocker is an important priority. High and urgent mean the same thing to me. Wish is fine, but that is too similar to low if you ask me. My ideal would be low, medium, high, blocker. Medium feels weird, but it's a real thing,

Re: Request to review feature-freeze proposed tickets

Hi, I would like to get as many of these as is feasible in. Before the feature freeze started 1 out of 17 JIRAs that were patch available were reviewed and committed. If you didn’t have access reviewers and committers, as the one out of the 17 did, it has been essentially impossible to get

Re: CASSANDRA-13241 lower default chunk_length_in_kb

more space efficient representation for compressed chunk offsets" for post 4.0. Regards, Ariel On Tue, Oct 23, 2018, at 11:46 AM, Ariel Weisberg wrote: > Hi, > > To summarize who we have heard from so far > > WRT to changing just the default: > > +1: > Jon Haddad

Re: Proposed changes to CircleCI testing workflow

Hi, Thank you for working on this. These all sound like good changes to me. Ariel On Fri, Oct 26, 2018, at 10:49 AM, Stefan Podkowinski wrote: > I'd like to give you a quick update on the work that has been done > lately on running tests using CircleCI. Please let me know if you have > any

Re: CASSANDRA-13241 lower default chunk_length_in_kb

Hi, I just asked Jeff. He is -0 and -0.5 respectively. Ariel On Tue, Oct 23, 2018, at 11:50 AM, Benedict Elliott Smith wrote: > I’m +1 change of default. I think Jeff was -1 on that though. > > > > On 23 Oct 2018, at 16:46, Ariel Weisberg wrote: > > > > Hi, &

Re: CASSANDRA-13241 lower default chunk_length_in_kb

Hi, To summarize who we have heard from so far WRT to changing just the default: +1: Jon Haddadd Ben Bromhead Alain Rodriguez Sankalp Kohli (not explicit) -0: Sylvaine Lebresne Jeff Jirsa Not sure: Kurt Greaves Joshua Mckenzie Benedict Elliot Smith WRT to change the representation: +1:

Re: CASSANDRA-13241 lower default chunk_length_in_kb

64k 25:33 32k 20:01 16k 19:19 16k 19:14 8k 16:51 4k 15:39 Ariel On Thu, Oct 18, 2018, at 2:55 PM, Ariel Weisberg wrote: > Hi, > > For those who were asking about the performance impact of block size on > compres

Re: CASSANDRA-13241 lower default chunk_length_in_kb

Elliott Smith wrote: > FWIW, I’m not -0, just think that long after the freeze date a change > like this needs a strong mandate from the community. I think the change > is a good one. > > > > > > > On 17 Oct 2018, at 22:09, Ariel Weisberg wrote: > > > >

Re: CASSANDRA-13241 lower default chunk_length_in_kb

as well, > > > > C*heers, > > --- > > Alain Rodriguez - al...@thelastpickle.com > > France / Spain > > > > The Last Pickle - Apache Cassandra Consulting > > http://www.thelastpickle.com > > > > Le sam. 13 oct. 201

Re: Implicit Casts for Arithmetic Operators

> return type. > > This would still leave a decision for float+double, though. The most > consistent behaviour with that stated above would be to always take the > most approximate type to return (i.e. float), but this would seem to me > to be fairly unexpected for the user

Re: Implicit Casts for Arithmetic Operators

Hi, I agree with what's been said about expectations regarding expressions involving floating point numbers. I think that if one of the inputs is approximate then the result should be approximate. One thing we could look at for inspiration is the SQL spec. Not to follow dogmatically

Re: Tested to upgrade to 4.0

Hi, Thanks for reporting this. I'll get this fixed today. Ariel On Fri, Oct 12, 2018, at 7:21 AM, Tommy Stendahl wrote: > Hi, > > I tested to upgrade to Cassandra 4.0. I had an existing cluster with > 3.0.15 and upgraded the first node but it fails to start due to a > NullPointerException. >

CASSANDRA-13241 lower default chunk_length_in_kb

Hi, This is regarding https://issues.apache.org/jira/browse/CASSANDRA-13241 This ticket has languished for a while. IMO it's too late in 4.0 to implement a more memory efficient representation for compressed chunk offsets. However I don't think we should put out another release with the

Re: Implicit Casts for Arithmetic Operators

ssify. > > > > On 2 Oct 2018, at 15:48, Ariel Weisberg wrote: > > > > Hi, > > > > I think we should decide based on what is least surprising as you mention, > > but isn't overridden by some other concern. > > > > It seems to me the p

Re: Implicit Casts for Arithmetic Operators

Hi, I think we should decide based on what is least surprising as you mention, but isn't overridden by some other concern. It seems to me the priorities are * Correctness * Performance * User visible complexity * Developer visible complexity Defaulting to silent implicit data loss is not

Re: Recommended circleci settings for DTest

/development/testing.rst#circleci > > > > On Fri, Sep 28, 2018 at 2:55 PM Ariel Weisberg wrote: > > > Hi, > > > > Apply the following diff and if you have access to the higher memory > > containers it should run the dtests with whatever you have. You may need t

Re: Recommended circleci settings for DTest

Hi, Apply the following diff and if you have access to the higher memory containers it should run the dtests with whatever you have. You may need to adjust parallelism to match whatever you paid for. diff --git a/.circleci/config.yml b/.circleci/config.yml index 5a84f724fc..76a2c9f841 100644

Re: Request for post-freeze merge exception

+1 Transient Replication had some rebase pain as well, but we were able to get through it at the last minute. The traffic on the last few days was pretty heavy with several substantial commits. On Tue, Sep 4, 2018, at 2:19 PM, Jeff Jirsa wrote: > Seems like a reasonable thing to merge to me.

Re: Transient Replication 4.0 status update

? Admittedly > > I'm not familiar with how much work has gone into fixing cluster expansion > > with vnodes, it is my understanding that you typically expand only one node > > at a time or in multiples of the datacenter size > > > > On Mon, Aug 27, 2018 at 12:29 PM Ar

Re: Transient Replication 4.0 status update

ith how much work has gone into fixing cluster expansion > with vnodes, it is my understanding that you typically expand only one node > at a time or in multiples of the datacenter size > > On Mon, Aug 27, 2018 at 12:29 PM Ariel Weisberg wrote: > > > Hi all, > > > > I

Transient Replication 4.0 status update

Hi all, I wanted to give everyone an update on how development of Transient Replication is going and where we are going to be as of 9/1. Blake Eggleston, Alex Petrov, Benedict Elliott Smith, and myself have been working to get TR implemented for 4.0. Up to now we have avoided merging anything

Re: upgrade guava on trunk before 9/1?

now. > > As I asked, "does anybody feeling strongly?". Personally, I'm sorta +0 to > +0.5, but I was just throwing this out there in case someone does really > think it best we upgrade (and wants to make a contribution). > > -Jason > > > > > On Wed, Aug

Re: upgrade guava on trunk before 9/1?

Hi, What do we get from Guava in exchange for upgrading? Ariel On Wed, Aug 15, 2018, at 10:19 AM, Jason Brown wrote: > Hey all, > > Does anyone feel strongly about upgrading guava on trunk before the 9/1 > feature freeze for 4.0? We are currently at 23.3 (thanks to > CASSANDRA-13997), and the

Re: GitHub PR ticket spam

Hi, Great idea. +1 to moving it to the work log. Thanks, Ariel On Mon, Aug 6, 2018, at 12:40 PM, Aleksey Yeshchenko wrote: > 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

Re: GitHub PR ticket spam

Hi, I really like having it mirrored. I would not be in favor of eliminating automated mirroring. What we are seeing is that removing the pain of commenting in JIRA is encouraging people to converse more in finer detail. That's a good thing. I have also seen the pain of how various github

Re: Improve the performance of CAS

Hi, I think you are looking at the right low hanging fruit. Cassandra deserves a better consensus protocol, but it's a very big project. Regards, Ariel On Wed, May 16, 2018, at 5:51 PM, Dikang Gu wrote: > Cool, create a jira for it, > https://issues.apache.org/jira/browse/CASSANDRA-14448. I

Re: Evolving the client protocol

pport might be to contribute an Apache >> licensed thread per core implementation in Java that matches the protocol >> change and shard concept you are looking for ;P > > I doubt I'll survive the egregious top-posting that is going on in this list. > >> >> >>

Re: Evolving the client protocol

t; This would give you a path forward at least for the short term. > > > > > > On Thu, Apr 19, 2018 at 12:10 PM Ariel Weisberg <ar...@weisberg.ws> wrote: > > > >> Hi, > >> > >> I think that updating the protocol spec to Cassandra puts the onu

Re: Evolving the client protocol

changes, but if no one commits to doing the work you might find we release the next protocol version without the tentative spec changes. Ariel On Thu, Apr 19, 2018, at 12:53 PM, Avi Kivity wrote: > > > On 2018-04-19 19:10, Ariel Weisberg wrote: > > Hi, > > > >

Re: Evolving the client protocol

Hi, I think that updating the protocol spec to Cassandra puts the onus on the party changing the protocol specification to have an implementation of the spec in Cassandra as well as the Java and Python driver (those are both used in the Cassandra repo). Until it's implemented in Cassandra we

Re: Roadmap for 4.0

Hi, +1 to September 1st. I know I will have much better availability then. Ariel On Thu, Apr 12, 2018, at 5:15 PM, Sankalp Kohli wrote: > +1 with Sept 1st as I am seeing willingness for people to test it after it > > > On Apr 12, 2018, at 13:59, Ben Bromhead wrote: > > >

Re: Roadmap for 4.0

Hi, What is the role of minor releases in Cassandra? I know that we have guarantees we make about minor releases that we don't make about major releases (is this summarized anywhere?), but is there anyone who actually thinks those guarantees are worth it vs having major releases on a shorter

Re: Roadmap for 4.0

Hi, +1 to having a feature freeze date. June 1st is earlier than I would have picked. Ariel On Thu, Apr 5, 2018, at 10:57 AM, Josh McKenzie wrote: > +1 here for June 1. > > On Thu, Apr 5, 2018 at 9:50 AM, Jason Brown wrote: > > > +1 > > > > On Wed, Apr 4, 2018 at 8:31

Re: question on running cassandra-dtests

efaultThreadFactory.java:138) [netty- > all-4.1.14.Final.jar:4.1.14.Final] > at java.lang.Thread.run(Thread.java:748) [na:1.8.0_151], ERROR > [MessagingService-NettyOutbound-Thread-4-7] 2018-03-28 00:24:37,063 > OutboundHandshakeHandler.java:209 - Failed to properly handshake with > peer 127.0.0.3

Re: question on running cassandra-dtests

Hi, Great! Glad you were able to get up and running. The dtests can be tricky if you aren't already somewhat familiar with Python. Ariel On Mon, Mar 26, 2018, at 9:10 PM, Murukesh Mohanan wrote: > On Tue, Mar 27, 2018 at 6:47 Ariel Weisberg <ar...@weisberg.ws> wrote: > > > H

Re: question on running cassandra-dtests

Hi, Your environment is python 2.7 when it should be python 3. See: > File "/usr/local/lib/python2.7/dist-packages/_pytest/assertion/ > rewrite.py", line 213, in load_module Are you using virtualenv to create a python 3 environment to use with the tests? >From README.md: **Note**: While

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

Hi, I'm not clear on what building and bundling our own JRE/JDK accomplishes? What is our source for JRE updates going to be? Are we going to build our own and does Oracle release the source for their LTS releases? Are we going to extract LTS updates from CentOS? If the goal of bundling is to

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

t; 08:42:43 CI ? It just let's your test matrix explode - a litte ;) > > 08:46:48 Michael Shuler yep, we currently `def jdkLabel = 'JDK 1.8 > > (latest)'` in job DSL and could easily modify that > > > > On Tue, Mar 20, 2018 at 9:08 AM, Kant Kodali <k...@peernova.com> wrote: >

Re: Debug logging enabled by default since 2.2

log. > > I guess in that configuration, some/most TRACE level loggings would then be > eligible to graduate to DEBUG...? > > > > > On Tue, Mar 20, 2018 at 4:19 PM Ariel Weisberg <ar...@weisberg.ws> wrote: > > > Hi, > > > > Signal to nois

Re: Debug logging enabled by default since 2.2

Hi, Signal to noise ratio matters for logs. Things that we log at DEBUG aren't at all bound by constraints of human readability or being particularly relevant most of the time. I don't want to see most of this stuff unless I have already not found what I am looking for at INFO and above. Can

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

Hi, +1 to what Jordan is saying. It seems like if we are cutting a release off of trunk we want to make sure we get N years of supported JDK out of it. For a single LTS release N could be at most 3 and historically that isn't long enough and it's very likely we will get < 3 after a release is

Re: Debug logging enabled by default since 2.2

Hi, In a way the real issue might be that we don’t have nightly performance runs that would make an accidentally introduced debug statement obvious. A log statement that runs once or more per read or write should be easy to spot. I haven’t measured the impact though. And as a bonus by having

Re: Making RF4 useful aka primary and secondary ranges

Hi, There is a JIRA for decoupling the size of the group size used for consensus with level of data redundancy. https://issues.apache.org/jira/browse/CASSANDRA-13442 It's been discussed quite a bit offline and I did a presentation on it at NGCC. Hopefully we will see some movement on it soon.

Re: Release votes

Hi, I created https://issues.apache.org/jira/browse/CASSANDRA-14241 for this issue. You are right there is a solid chunk of failing tests on Apache infrastructure that don't fail on CircleCI. I'll find someone to get it done. I think that fix before commit is only going to happen if we go all

Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE

Hi, Option 4, upgrade trunk, update NEWS.TXT in prior versions warning about the vulnerability. Ariel On Tue, Feb 13, 2018, at 12:28 PM, Ariel Weisberg wrote: > Hi, > > So our options are: > > 1. Ignore it. > Most people aren't using this functionality. > Most people

Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE

going to break some apps according to Michael Shuler. Happened when he tried it. Certainly we can upgrade in trunk? While we are at it come up to the latest version. Ariel On Tue, Feb 13, 2018, at 12:03 PM, Ariel Weisberg wrote: > Hi, > > I don't think the fix is in 1.1.11 looking at

Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE

we support - which is 2.1 and higher. > > > > Also, is this worth stopping the current open vote for this patch? (Not in > > a place to look at the patch and affects to impacted branches right now). > > > > Jason > > > > On Tue, Feb 13, 2018 at 08:43 Ariel Weisbe

Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE

Hi, Seems like users could conceivably be using the vulnerable component. Also seems like like we need potentially need to do this as far back as 2.1? Anyone else have an opinion before I commit this? What version to start from? Ariel On Tue, Feb 13, 2018, at 5:59 AM, Thiago Veronezi wrote: >

Cassandra 7544 configurable storage port and you

Hi, I want to bring up some important changes to how addresses should be handled in Cassandra after 7544. As of 7544 a Cassandra instance (sometimes referred to as a node in the code) can't be identified by an InetAddress. It can't be identified for the purposes of the internal storage

Re: Soliciting volunteers for flaky dtests on trunk

d on https://issues.apache.org/jira/browse/CASSANDRA-13182. > > > > On 11 May 2017 at 05:59, Blake Eggleston <beggles...@apple.com> wrote: > > > > > I've taken CASSANDRA-13194, CASSANDRA-13506, CASSANDRA-13515, > > > and CASSANDRA-13372 to start >

Re: Soliciting volunteers for flaky dtests on trunk

: cqlsh_tests.CqlshSmokeTest.[test_insert | test_truncate | test_use_keyspace | test_create_keyspace] JIRA: No JIRA yet Last failed: 4/22/2017 count: 6 If you have spare cycles you can make a huge difference in test stability by picking off one of these. Regards, Ariel On Wed, May 10, 2017, at 12:45 PM, Ariel Weisberg

Soliciting volunteers for flaky dtests on trunk

Hi all, The unit tests are looking pretty reliable right now. There is a long tail of infrequently failing tests but it's not bad and almost all builds succeed in the current build environment. In CircleCI it seems like unit tests might be a little less reliable, but still usable. The dtests on

Re: Proposal: push TravisCI and CircleCI yaml files into the active branches

Hi, I think we should support something that we can scale out and that can produce consistent reproducible results. One of the longer term issues is going to be different CI systems producing different sets of failures. It's not going to happen often but it will and it's one way flakiness will

Re: [DISCUSS] Implementing code quality principles, and rules (was: Code quality, principles and rules)

Hi, Code coverage: I value code coverage as part of the review and development process. As a project wide target I think it's not as high value, but having a standard encourages people to take the time to use the tools and that's a healthy side effect. Code coverage is a measure of code

Re: committing performance patches without performance numbers

Hi, I should clarify. Should in the sense of it was fine for the process we had at the time (ugh!) but it's not what we should do in the future. Ariel On Thu, Mar 9, 2017, at 04:55 PM, Ariel Weisberg wrote: > Hi, > > I agree that patch could have used it and it was amenable t

Re: committing performance patches without performance numbers

st, Set and Map serialization. Would it really > have been that crazy to run a handful of benchmarks locally and post > those > results? > > On Thu, Mar 9, 2017 at 12:26 PM Ariel Weisberg <ar...@weisberg.ws> wrote: > > > Hi, > > > > I think there

Re: Testing and jira tickets

Hi, Before this change I had already been queuing the jobs myself as a reviewer. It also happens to be that many reviewers are committers. I wouldn't ask contributors to run the dtests/utests for any purpose other then so that they know the submission is done. Even if they did and they pass it

Re: committing performance patches without performance numbers

Hi, I think there are issues around the availability of hardware sufficient to demonstrate the performance concerns under test. It's an open source project without centralized infrastructure. A lot of performance contributions come from people running C* in production. They are already running

Re: Per blockng release on dtest

Hi, The upgrade tests are tricky because they upgrade from an existing release to a current release. The bug is in 3.9 and won't be fixed until 3.11 because the test checks out and builds 3.9 right now. 3.10 doesn't include the commit that fixes the issue so it will fail after 3.10 is released

Re: Per blockng release on dtest

without the burden of an ever-later slipped release hanging > over our heads. There's plenty of bugfixes in the 3.X line; the more time > people can have to kick the tires on that code, the more things we can > find > and the better future releases will be. > > >

Re: Wrapping up tick-tock

Hi, With yearly releases trunk is going to be a mess when it comes time to cut a release. Cutting releases is when people start caring whether all the things in the release are in a finished state. It's when the state of CI finally becomes relevant. If we wait a year we are going to accumulate a

Re: Per blockng release on dtest

Hi, At least some of those failures are real. I don't think we should release 3.10 until the real failures are addressed. As I said earlier one of them is a wrong answer bug that is not going to be fixed in 3.10. Can we just ignore failures because we think they don't mean anything? Who is going

Re: 3.10 release status: blocked on dtest

Hi, When we say all tests passing it does seem like we are including the upgrade tests, but there are some failures that don't seem to have tickets blocking the release. It seems like we are also excluding any tests decorated as resource intensive? There is also large_dtest, novnode_dtest, and

Re: Use of posix_fadvise

, Michael Kjellman wrote: > Within a single SegmentedFile? > > On Oct 18, 2016, at 9:02 AM, Ariel Weisberg > <ariel.weisb...@datastax.com<mailto:ariel.weisb...@datastax.com>> wrote: > > With compaction there can be hot and cold data mixed together. >

Re: Use of posix_fadvise

Hi, With compaction there can be hot and cold data mixed together. So we want to drop the data and then warm it via early opening so only the hot data is in the cache. Some of those cases are for the old sstable that have been rewritten or discarded so the data is entirely defunct. The files

End June retrospective, July retrospective will start @ C* summit

Hi all, I am closing out July retrospective now. The retrospective doc has a single author (me) which kind of says that doing this asynchronously by email isn't working. At least not as a starting point. I am not super surprised nor am I disappointed. Trying and failing is part of eventually

Re: Should we make everything blue in Jenkins?

Hi, Thanks for bring this up Michael. I want to elaborate on the impetus for this (or at least my take on it). When 8099 merged we had a thing that must never happen for our process to work. We introduced a large enough number of test failures that it was difficult to tell if you introduced a

Re: Proposal, add Epic to the set of issue types available in ASF Jira for Cassandra

, 2015 at 12:42 PM, Ariel Weisberg ariel.weisb...@datastax.com wrote: Hi, At this stage I wasn't going to propose a process change. My goal is to observe and report mall cop style so I can present what happens the way we currently operate. Right now Epics are just a way for me to bucket

Re: Proposal, add Epic to the set of issue types available in ASF Jira for Cassandra

to the release (Materialized Views, 8099), bugs or failing tests. Regards, Ariel On Wed, Aug 5, 2015 at 11:43 AM, Gary Dusbabek gdusba...@gmail.com wrote: Who would have the burden of assigning and managing epics? Thanks, Gary. On Tue, Aug 4, 2015 at 3:08 PM, Ariel Weisberg

  1   2   >