CI git polling for changes on a separate repository (if/when CI is
needed) is probably a better way to go. I don't believe there are any
issues with INFRA on us having discrete repos, and creating them with
the self-help web tool is quick and easy.
Thanks for the neat looking utility!
Michael
On 8/22/19 10:33 AM, Sankalp Kohli wrote:
A different repo will be better
On Aug 22, 2019, at 6:16 AM, Per Otterström <per.otterst...@ericsson.com> wrote:
Very powerful tool indeed, thanks for sharing!
I believe it is best to keep tools like this in different repos since different
tools will probably have different life cycles and tool chains. Yes, that could
be handled in a single repo, but with different repos we'd get natural
boundaries.
-----Original Message-----
From: Sumanth Pasupuleti <spasupul...@netflix.com.INVALID>
Sent: den 22 augusti 2019 14:40
To: dev@cassandra.apache.org
Subject: Re: Contributing cassandra-diff
No hard preference on the repo, but just excited about this tool! Looking
forward to employing this for upgrade testing (very timely :))
On Thu, Aug 22, 2019 at 3:38 AM Sam Tunnicliffe <s...@beobal.com> wrote:
My own weak preference would be for a dedicated repo in the first
instance. If/when additional tools are contributed we should look at
co-locating common stuff, but rushing toward a monorepo would be a
mistake IMO.
On 22 Aug 2019, at 11:10, Jeff Jirsa <jji...@gmail.com> wrote:
I weakly prefer contrib.
On Thu, Aug 22, 2019 at 12:09 PM Marcus Eriksson
<marc...@apache.org>
wrote:
Hi, we are about to open source our tooling for comparing two
cassandra clusters and want to get some feedback where to push it.
I think the options are: (name bike-shedding welcome)
1. create repos/asf/cassandra-diff.git 2. create a generic
repos/asf/cassandra-contrib.git where we can add
more
contributed tools in the future
Temporary location:
https://protect2.fireeye.com/url?k=e8982d07-b412e678-e8986d9c-86717
581b0b5-292bc820a13b7138&q=1&u=https%3A%2F%2Fgithub.com%2Fkrummas%2
Fcassandra-diff
Cassandra-diff is a spark job that compares the data in two
clusters -
it
pages through all partitions and reads all rows for those
partitions in both clusters to make sure they are identical. Based
on the
configuration
variable “reverse_read_probability†the rows are either read
forward or
in
reverse order.
Our main use case for cassandra-diff has been to set up two
identical clusters, transfer a snapshot from the cluster we want to
test to these clusters and upgrade one side. When that is done we
run this tool to
make
sure that 2.1 and 3.0 gives the same results. A few examples of the
bugs we
have found using this tool:
* CASSANDRA-14823: Legacy sstables with range tombstones spanning
multiple
index blocks create invalid bound sequences on 3.0+
* CASSANDRA-14803: Rows that cross index block boundaries can cause
incomplete reverse reads in some cases
* CASSANDRA-15178: Skipping illegal legacy cells can break reverse
iteration of indexed partitions
/Marcus
-------------------------------------------------------------------
-- 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
B‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB•È [œÝXœØÜšX™KK[XZ[ˆ]‹][œÝXœØÜšX™PØ\ÜØ[™ ˜K˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ ËK[XZ[ˆ]‹Z[ Ø\ÜØ[™ ˜K˜\XÚK›Ü™ÃBƒB
---------------------------------------------------------------------
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
