I can help out.
Dinesh
On Friday, May 11, 2018, 4:37:07 PM PDT, kurt greaves
wrote:
Oh I know, there are just tickets relevant to people I work with.
On Fri., 11 May 2018, 22:10 Josh McKenzie, wrote:
> May be easier to just provide a link to the JQL, since there's quite a few
> more
+1 on doing this on a case-by-case basis. The threadpool_metrics looks
reasonable. It's best not to shoehorn all metrics into a single table with all
possible columns.
Dinesh
On Friday, June 22, 2018, 8:11:33 AM PDT, Chris Lohfink
wrote:
I think this can really be case by case. In tp
I think the call to action for the community here is to focus efforts on
testing and bug fixes than spending time on reviewing features. That said,
tlp-stress looks interesting.
Dinesh
On Tuesday, July 3, 2018, 1:03:54 PM PDT, Jonathan Haddad
wrote:
I agree with Josh. I don’t see how
Kurt was looking at some help with this ticket -
https://issues.apache.org/jira/browse/CASSANDRA-14525
Dinesh
On Tuesday, July 17, 2018, 12:35:25 PM PDT, sankalp kohli
wrote:
Hi,
We are 7 weeks away from 4.0 freeze and there are ~150 JIRAs waiting
for review. It is hard to know wh
I can help out with the triage / rerunning dtests if needed.
Dinesh
On Monday, July 23, 2018, 10:22:18 AM PDT, Jason Brown
wrote:
I spoke with some people over here, and I'm going to spend a day doing a
quick triage of the failing dtests. There are some fixes for data loss bugs
that ar
ry to corral those with any new ones.
Thanks,
-Jason
On Mon, Jul 23, 2018 at 10:26 AM, dinesh.jo...@yahoo.com.INVALID <
dinesh.jo...@yahoo.com.invalid> wrote:
> I can help out with the triage / rerunning dtests if needed.
> Dinesh
>
> On Monday, July 23, 2018, 10:22:18 AM PDT,
On Tue, Jul 24, 2018 at 9:03 AM, dinesh.jo...@yahoo.com.INVALID <
dinesh.jo...@yahoo.com.invalid> wrote:
> Hi Jason,
> I agree - we should release with the dataloss bug fix. I went over the
> gist - apart from the Python errors and test teardown failures, there seem
> to be a f
+1
Dinesh
On Wednesday, July 25, 2018, 12:46:20 AM PDT, Michael Shuler
wrote:
I propose the following artifacts for release as 3.11.3.
sha1: 31d5d870f9f5b56391db46ba6cdf9e0882d8a5c0
Git:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.3-tentative
Art
+1
Dinesh
On Wednesday, July 25, 2018, 12:47:34 AM PDT, Michael Shuler
wrote:
I propose the following artifacts for release as 3.0.17.
sha1: d52c7b8c595cc0d06fc3607bf16e3f595f016bb6
Git:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.17-tentative
Ar
+1
Dinesh
On Wednesday, July 25, 2018, 12:49:09 AM PDT, Michael Shuler
wrote:
I propose the following artifacts for release as 2.2.13.
sha1: 3482370df5672c9337a16a8a52baba53b70a4fe8
Git:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.13-tentative
Ar
It is useful to have a historical record. However, it could definitely be
better (huge diffs are pointless).
Thanks,
Dinesh
On Monday, July 30, 2018, 1:27:26 AM PDT, Stefan Podkowinski
wrote:
Looks like we had some active PRs recently to discuss code changes in
detail on GitHub, which
+1 for preserving it as worklog.
Dinesh
P.S.: Apologies for the github spam :-)
On Monday, August 6, 2018, 3:09:28 PM PDT, Mick Semb Wever
wrote:
>
> Great idea. +1 to moving it to the work log.
>
https://issues.apache.org/jira/browse/INFRA-16879
Nice! Thanks for getting this done.
Dinesh
On Wednesday, August 8, 2018, 2:21:22 PM PDT, Mick Semb Wever
wrote:
> >
> > Great idea. +1 to moving it to the work log.
> >
>
> https://issues.apache.org/jira/browse/INFRA-16879
This is working now.
See eg https://issues.apache.org/ji
Jason,
Given that we're so close to the 9/1 date, I would err on the side of caution
especially given the low value prop. If someone does run into Guava
compatibility issues (and someone somewhere will), we can revisit this question
then.
Dinesh
On Wednesday, August 15, 2018, 11:42:31 PM P
basically for all
> > > the reasons listed below. I'm assuming we'd want a management process to
> > > work across different versions, which will be more awkward if it's in
> > tree.
> > > Even if that's not the case, keeping it in a diff
Hi Jeff,
Thanks for the patch. I assigned the ticket to you. I'll be happy to review the
ticket later today.
Dinesh
On Friday, August 17, 2018, 1:24:33 PM PDT, Jeff Beck
wrote:
I submitted a patch for the feed to that ticket it also seemed like we
needed bundler to ensure we always us
On Mon, Aug 20, 2018 at 4:23 AM Mick Semb Wever wrote:
>
> We are looking to contribute Reaper to the Cassandra project.
>
> Looking at the patch it's very similar in its base design already, but
> Reaper does has a lot more to offer. We have all been working hard to move
> it to also being a side
An option is to create a mono repo with Cassandra and SideCar as modules that
could be built independently. This would keep source for both artifacts in the
same repo and have their own release cadences. That said, I don't have any
strong opinions at this point. We can try going with a separate
I think we should have the ability to build & run unit tests and dtests against
a specified JDK. If we support multiple JDKs, at a minimum we should compile
code against those JDKs. It would be ideal if we could run unit tests and
dtests but given the availability of CircleCI resources that coul
On Tuesday, August 28, 2018, 2:52:03 PM PDT, Blake Eggleston
wrote:
> I’m sure reaper will bring tech debt with it, but I doubt it's a hopeless
> mess.
FTR nobody has called Reaper a "hopeless mess".
> It would bring a relatively mature project as well as a community of users>
> and developers
I like the idea of having an officially supported Go Driver under ASF. It would
mean easier contributions.
I don't think we should necessarily limit it to a reference implementation. The
industry has a strong interest in building server side as well as client
software in Go.
Dinesh
On Friday
+1
Dinesh
On Tuesday, September 4, 2018, 12:51:49 PM PDT, Ariel Weisberg
wrote:
+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, S
I have a few clarifications -
The scope of the management process is not to simply run repair scheduling.
Repair scheduling is one of the many features we could implement or adopt from
existing sources. So could we please split the Management Process discussion
and the repair scheduling?
After r
t and I don't see it as antithetical to what I had in mind with Reaper.
Rather, the two are more complementary than I had originally realized.
Jon
On Thu, Sep 13, 2018 at 10:39 AM dinesh.jo...@yahoo.com.INVALID
wrote:
> I have a few clarifications -
> The scope of the management proce
t; with this
> 1. Bulk nodetool commands: User can curl any sidecar and be able to run a
> nodetool command in bulk across the cluster.
> :/bulk/nodetool/tablestats?arg0=keyspace_name.table_name&arg1= required>
>
> And later
> 2: Health checks.
>
> On Thu, Se
Logistics aside, I think it is a good idea to default 1 token (or a low
number). Let the user understand what it means to go beyond 1 and tune things
based on their needs.
Dinesh
On Friday, September 21, 2018, 5:06:14 PM PDT, Jonathan Haddad
wrote:
One thing that's really, really bot
*bump*
Mick - could you enumerate the list of tools you mentioned earlier?
Dinesh
On Sunday, September 23, 2018, 6:22:48 PM PDT, Dinesh Joshi
wrote:
Hi Mick,
Thanks for the feedback. Please find my clarifications inline.
> There's also been suggestions to take a step away from any f
Thanks for starting this, Mick. I will flesh it out.
Dinesh
On Sunday, October 21, 2018, 1:52:10 AM PDT, Mick Semb Wever
wrote:
> But I'll try to put together a strawman proposal for the doc(s) over the
> weekend.
I've thrown something quickly together here:
- https://cwiki.apach
Hi Georg,
I took a look at your patch and left some comments on the ticket.
Thanks,
Dinesh
On Friday, November 16, 2018, 12:04:39 PM PST, Jeff Jirsa
wrote:
The assignment is just so you get “credit” for the patch - asking for a
reviewer is good but not strictly necessary.
(Some of t
waiting indefinitely.
>
> Thanks,
>
> Dinesh
>
>> On Oct 22, 2018, at 7:30 AM, "dinesh.jo...@yahoo.com.INVALID"
>> wrote:
>>
>> Thanks for starting this, Mick. I will flesh it out.
>> Dinesh
>>
>> On Sunday, October 21, 2018, 1:52:10
You're probably hitting this -
https://github.com/datastax/cpp-driver/blob/2.0/src/session.cpp#L740
>From my reading it feels you may want to throttle your queries or play around
>with the driver settings. Essentially it seems the number of queries you're
>issuing is greater than what the cluste
Kurt, I don't believe this should be subject of "heated debate". If those
tickets were sitting in patch available state prior to the freeze they *should*
get in.
Vinay, I can help review the tickets.
Dinesh
On Tuesday, November 20, 2018, 2:59:18 PM PST, kurt greaves
wrote:
Thanks Vin
To clarify send an empty email (no subject or body) to
dev-unsubscr...@cassandra.apache.org
You will then get a confirmation email with a link. Click that.
Dinesh
On Tuesday, November 20, 2018, 6:20:34 PM GMT+2, Michael Shuler
wrote:
On 11/20/18 10:15 AM, Versátil wrote:
>
> I alread
I've been already using github PRs for some time now. Once you specify the
ticket number, the comments and discussion are persisted in Apache Jira as work
log so it can be audited if desired. However, committers usually squash and
commit the changes once the PR is approved. We don't use the merg
I think it makes sticking to trunk as this change will affect log messages and
may break tooling that depends on certain patterns.
Dinesh
On Friday, December 14, 2018, 4:09:51 PM GMT+5:30, Jasonstack Zhao Yang
wrote:
Hi,
Would like to get some feedback for CASSANDRA-14925.
In order
Hi Fumiya, I'm looking at it this week.
Dinesh
On Sunday, February 3, 2019, 9:46:35 PM PST, Fumiya Yamashita
wrote:
Hello.
I have created a ticket for the improvement of nodetool.
(https://issues.apache.org/jira/browse/CASSANDRA-14847)
I’d like this patch to be merged to Cassandra 4.
Hey all,
We've gotten the cqlsh tests running in the Cassandra repo (these are distinct
from the cqlsh tests in dtests repo). They're in Python 2.7 and using the
nosetests. We'd like to make them consistent with the rest of the tests which
means moving them to Python 3 & Pytest framework. Howeve
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 (these are
>> distinct from the cqlsh tests in dtests repo). They're in Python 2.7 and
46 PM dinesh.jo...@yahoo.com.INVALID
wrote:
I saw that thread and the tickets. They haven't had any activity recently.
Given that it is already Feb 2019 and Python 2.7 is getting close to EOL'd, I
think it's worth moving forward with deprecating Python 2.7 support and adding
3.0
Thanks Ariel & Jonathan.
Michael, I have addressed the comments in the issue so we're using the latest
jar now. I've posted the updated patch in the latest comment of the ticket. In
addition there is a JMH performance benchmark in the C* repo
(CompressorPerformance) that tests various Compressor
Thanks all for your input. The consensus is to go forward with this ticket.
Dinesh
On Friday, February 15, 2019, 12:54:20 PM PST, Sumanth Pasupuleti
wrote:
+1
On Fri, Feb 15, 2019 at 12:14 PM Dikang Gu wrote:
> +1
>
> On Fri, Feb 15, 2019 at 10:27 AM Vinay Chella
> wrote:
>
> > We
Hi all,
Apologies for the cross-post. In case you're in the SF Bay Area, Instagram is
hosting a meetup. Interesting talks on Cassandra Traffic management, Cassandra
on Kubernetes. See details in the attached link -
https://www.eventbrite.com/e/cassandra-traffic-management-at-instagram-cassandra-
>> On Feb 18, 2019, at 6:40 PM, Shaurya Gupta wrote:
>>>
>>> Hi,
>>>
>>> This looks very interesting to me. Can I attend this remotely?
>>>
>>> Thanks
>>> Shaurya
>>>
>>>
>>> On Tue, Feb 19, 2019
+1 to everything Jeff said. As someone who has worked on flaky tests not just
in Cassandra's context, I know it can be hard to deal with them.
However, it's best to root cause them. I have found some flaky tests were
genuine issues that needed fixing in Cassandra. Sometimes the flakiness is due
44 matches
Mail list logo
