+1 for separate repo. On Fri, Aug 23, 2019 at 9:29 AM Yifan Cai <yc25c...@gmail.com> wrote:
> Great addition in the tool set! > > A separate repo would be better. > > Grouping repos together only to be easier indexed does not seems to be a > strong supportive reason. Just my 2 cents. > > - Yifan > > - Yifan > > ________________________________ > From: Dinesh Joshi <djo...@apache.org> > Sent: Thursday, August 22, 2019 11:42 AM > To: dev > Subject: Re: Contributing cassandra-diff > > +1 on a discrete repo. > > Dinesh > > > On Aug 22, 2019, at 9:14 AM, Michael Shuler <mich...@pbandjelly.org> > wrote: > > > > 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™K K[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 > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > -- regards, Laxmikant Upadhyay
