Congratulations Patrick! Well deserved.
Jordan
On Thu, Feb 2, 2023 at 10:18 Brandon Williams wrote:
> Congratulations, Patrick!
>
> Kind Regards,
> Brandon
>
> On Thu, Feb 2, 2023 at 11:58 AM Benjamin Lerer wrote:
> >
> > The PMC members are pleased to announce that Patrick McFadin has accepte
Hi,
I’m wondering if there is appetite to change the default SSL provider for
Cassandra going forward to either ACCP [1] or tc-native in Netty? Our
deployment as well as others I’m aware of make this change in their fork
and it can lead to significant performance improvement. When recently
qualify
tographic primitives beyond TLS
> acceleration for Netty.
>
>
>
> On Jun 22, 2023, at 2:07 PM, Jeff Jirsa wrote:
>
>
>
>
>
> Either would be better than today.
>
>
>
> On Thu, Jun 22, 2023 at 1:57 PM Jordan West wrote:
>
> Hi,
>
>
>
> I
I left my comments on the JIRA itself but generally they mirror Scott and
Joeys thoughts.
Jordan
On Wed, Jul 26, 2023 at 07:26 C. Scott Andreas wrote:
> Peter, thanks for your message.
>
> You are receiving these emails because your address is subscribed to the
> Apache Cassandra "dev@" develop
We do and I’m sensitive to that 100% but there is no reason ACCP should
break upgrades afaik. The algorithms it implements are identical and for
the ones it doesn’t the JRE implementation is used — ACCP is the higher
priority implementation. Do we have any examples of it breaking anything?
Or that
+1 Scott. And agreed all involved are looking out for the best interests of
C* users. And I appreciate those with concerns contributing to addressing
them.
I’m all for making upgrades smooth bc I do them so often. A huge portion of
our 4.1 qualification is “will it break on upgrade”? Because of th
n I do not see anyone who is against
> that?
>
> -Jeremiah
>
>
> On Jul 26, 2023 at 2:53:02 PM, Jordan West wrote:
>
>> +1 Scott. And agreed all involved are looking out for the best interests
>> of C* users. And I appreciate those with concerns contributing to
>>
I would also like to back this proposal. We change this default because
several incidents have occurred by leaving the default of auto. There are
rare cases where auto/mmap is the better option but as for a default
mmap_index_only is safer.
On Wed, Nov 15, 2023 at 6:35 AM Paulo Motta wrote:
> Hi
Thanks for proposing this CEP! We have something like this internally so I
have some familiarity with the approach and the challenges. After reading
the CEP a couple things come to mind:
1. I would like to see more abstraction of how the files get moved / put in
place with the proposed solution be
If we are considering the main process then we have to do some additional
work to ensure that it doesn’t put pressure on the JVM and introduce
latency. That’s one thing I like about having it an external process — not
that it’s bullet proof but it’s one less thing to worry about.
Jordan
On Thu, A
I do really like the framing of replacing a node is restoring a node and
then kicking off a replace. That is effectively what we do internally.
I also agree we should be able to do data movement well both internal to
Cassandra and externally for a variety of reasons.
We’ve seen great performance
I would likely commit to it as well
Jordan
On Mon, Apr 29, 2024 at 10:55 David Capwell wrote:
> So: besides Jon, who in the community expects/desires to maintain this
> going forward?
>
>
> I have been maintaining a fork for years, so don’t mind helping maintain
> this project.
>
> On Apr 28, 2
I’m a big +1 on 18917 or more testing of gossip. While I appreciate that it
makes TCM more complicated, gossip and schema propagation bugs have been
the source of our two worst data loss events in the last 3 years. Data loss
should immediately cause us to evaluate what we can do better.
We will li
On Wed, May 1, 2024 at 3:34 AM Alex Petrov wrote:
>
> We can implement CEP-40 using a similar approach: we can leave the source
> node as both a read and write target, and allow the new node to be a target
> for (pending) writes. Unfortunately, this does not help with availability
> (in fact, it
I would also love to see CCM as an official side project. It is important
to the project and I personally use it regularly.
Jordan
On Thu, May 16, 2024 at 7:55 AM Josh McKenzie wrote:
> We do still have the issues of DSE-supporting code in it, as we do with
> the drivers. I doubt any of us str
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č <
stefan.mikloso...@gmail.com> wrote:
> I have created
>
> https://issues.apache.org/jira/browse/CASSANDRA-19673
>
> to gather all your ideas about what to remove. If y
Agreed Aleksey. I wouldn’t be opposed to more nuanced use but the burden
that adds seems impractical. A simple rule is easier.
Jordan
On Fri, Jun 7, 2024 at 05:59 Aleksey Yeshchenko wrote:
> It am okay with its use off hot paths in principle, and I’ve done it
> myself.
>
> But as others have me
I am generally for this CEP, particularly the sizeOf guardrail. For
example, we recently had an incident caused by a client who wrote outside
of the contract we had verbally established. The constraint would have let
us encode that contract into the database. In this case, clients are
writing large
+1
On Fri, Jun 28, 2024 at 05:56 wrote:
> +1
>
>
> On Jun 27, 2024, at 3:03 PM, Josh McKenzie wrote:
>
> +1
>
> On Thu, Jun 27, 2024, at 12:40 AM, Abhijeet Dubey wrote:
>
> +1
>
> On Thu, Jun 27, 2024 at 1:47 AM Francisco Guerrero
> wrote:
>
> +1
>
> On 2024/06/21 15:13:31 Venkata Hari Krishna
+1
On Tue, Jul 2, 2024 at 12:15 Francisco Guerrero wrote:
> +1
>
> On 2024/07/02 18:45:33 Josh McKenzie wrote:
> > +1
> >
> > On Tue, Jul 2, 2024, at 1:18 PM, Abe Ratnofsky wrote:
> > > +1 (nb)
> > >
> > >> On Jul 2, 2024, at 12:15 PM, Yifan Cai wrote:
> > >>
> > >> +1 on CEP-42.
> > >>
> > >>
Hi Roman,
I was able to reproduce the issue you described. I filed
https://issues.apache.org/jira/browse/CASSANDRA-14479. More details there.
Thanks for reporting!
Jordan
On Wed, May 23, 2018 at 12:06 AM, Roman Bielik <
roman.bie...@openmindnetworks.com> wrote:
> Hi,
>
> I apologise for a late
On Tue, Jun 26, 2018 at 3:08 PM, Abdelkrim Fitouri
wrote:
> Hello,
>
> I am studying the gossip part on casssandra and wondering about the
> difference between the heartbeat and generation data exchanged for the
> autodiscovery.
>
> many thanks for any help.
>
If you haven’t had a chance to che
+1 (non-binding)
On Fri, Jul 13, 2018 at 5:02 AM, J. D. Jordan
wrote:
> -0 (non-binding) as well for similar reasons to Gary.
>
> > On Jul 12, 2018, at 8:23 AM, Gary Dusbabek wrote:
> >
> > -0
> >
> > I'm not interested in sparking a discussion on this, because a) it has
> > already happened an
+1 (nb) for the worklog approach.
Jordan
On Mon, Aug 6, 2018 at 4:53 PM dinesh.jo...@yahoo.com.INVALID
wrote:
> +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 <
> m...@apache.org> wrote:
>
>
>
Thanks for staring this thread Jon!
On Thu, Sep 6, 2018 at 5:51 AM Jonathan Haddad wrote:
> For 4.0, I'm thinking it would be a good idea to put together a list of the
> things that need testing and see if people are willing to help test / break
> those things. My goal here is to get as much co
I think this feature is important to the community and I don’t want to
stifle that but if committers/contributors are working on the management
process instead of testing 4.0 it takes away from it regardless of where
the code lives. Waiting to merge until after 4.0, at a minimum, would
benefit the
A couple related JIRAs for reference:
https://issues.apache.org/jira/browse/CASSANDRA-14714
https://issues.apache.org/jira/browse/CASSANDRA-14712
On Wed, Mar 6, 2019 at 7:34 PM Michael Shuler
wrote:
> On 3/6/19 7:10 PM, Stefan Miklosovic wrote:
> > I am trying to build 4.0 from sources and prio
On Mon, Mar 18, 2019 at 7:52 PM Michael Shuler
wrote:
> On 3/18/19 9:06 PM, Patrick Bannister wrote:
> > I recommend we pick the longest supported stable release available. That
> > would be Python 3.7, which is planned to get its last release in 2023,
> four
> > years from now.
> > - Python 3.5
In September, the community chose to freeze trunk to begin working on
Quality and Stability with the goal of releasing the most stable Cassandra
major in the project’s history. While lots of work has been ongoing and
folks could follow along with progress on JIRA I thought it would be useful
to cov
There is a lot of discuss here so I’ll try to keep my opinions brief:
1. The bug fixes are a requirement in order to have a stable 4.0. Whether
they come from this patch or the original I have less of an opinion. I do
think its important to minimize code changes at this time in the
development/fre
Concentrating on a smaller subset doesn't make a patch
> smaller,
> >> just helps to guide reviewers and observers, so my primary goal was to
> help
> >> people, hence my reference to the jira comment I'm working on.
> >>
> >>
> >> On Wed,
we
> landed on it. Any idea on how are we doing on that front?
>
> Thanks,
>
> Dinesh
>
> [1]
> https://lists.apache.org/thread.html/3a444be1a3097c0c55d15268ccb0fe7aab83ef276b87bf55bf4f3bc2@%3Cdev.cassandra.apache.org%3E
>
> > On Apr 10, 2019, at 8:25 AM, Jordan
Since their seems to be an assumption that I haven’t read the code let me
clarify: I am working on making time to be a reviewer on this and I have
already spent a few hours with the patch before I sent any replies, likely
more than most who are replying here. Again, because I disagree on
non-techni
+1 nb — to both the document and the benefits listed in Scott’s email.
Jordan
On Fri, Oct 4, 2019 at 2:26 PM Scott Andreas wrote:
> There are two main benefits to agreeing on this:
>
> 1. Providing clarity for contributors on release phases – i.e., what types
> of changes are expected to land o
+1 nb
On Wed, Oct 9, 2019 at 11:00 PM Per Otterström
wrote:
> +1 nb
>
> -Original Message-
> From: Mick Semb Wever
> Sent: den 10 oktober 2019 07:08
> To: dev@cassandra.apache.org
> Subject: Re: [VOTE-2] Apache Cassandra Release Lifecycle
>
>
> > We have discussed in the email threa
Extra time contributed to the project by an experienced community member in
either developer or project management areas would be very helpful in
completing 4.0. Thanks for volunteering Josh -- and +1 on thanking Scott
for his existing efforts (and Benedict and others who worked to improve the
JIRA
Thanks Patrick. Looking forward to tomorrow’s meeting. I added an agenda
item around 4.0 — it’s not my intention to lead that section necessarily
but I think a check in / progress update / follow up on Josh’s email will
be good to cover.
Jordan
On Mon, Jan 13, 2020 at 6:11 PM Patrick McFadin wro
Hi Everyone,
Josh is traveling this week so he sent me a brief summary and I offered to
send it to the mailing list w/ a few updates. There was enough progress in
the last week to warrant an update.
The 4.0 board can be found at
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355.
On Thu, Jan 23, 2020 at 9:09 AM Jeff Jirsa wrote:
> On Thu, Jan 23, 2020 at 6:18 AM Jeremiah Jordan
> wrote:
>
> > It is the reviewer and authors job to make sure CI ran and didn’t
> > introduce new failing tests, it doesn’t matter how they were ran. It is
> > just as easy to let something throu
Keeping trunk green at all times is a great goal to strive for, I'd love to
continue to work towards it, but in my experience its not easy. Flaky
tests, for the reason folks mentioned, are a real challenge. A standard we
could use while we work towards the more ambitious one, and we are pretty
clos
On Fri, Jan 24, 2020 at 11:23 AM Jordan West wrote:
>
> > Keeping trunk green at all times is a great goal to strive for, I'd love
> to
> > continue to work towards it, but in my experience its not easy. Flaky
> > tests, for the reason folks mentioned, are a real chall
That’s awesome that we have that set up. I was checking out b.a.o after my
email and noticed some recent runs. I don’t mean to prescribe any specific
way of surfacing results as long as they are easily accessible to all
contributors (well documented where to find them, etc).
Progress on posting re
Thanks for taking this up Josh. I'm for whatever we think will result in a
more accurate view of progress. Edit access has been a friction point. I'd
like to hear from others as well too but generally I'm +1 to giving it a
shot.
Jordan
On Thu, Jan 30, 2020 at 1:45 PM Joshua McKenzie
wrote:
> Fr
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 cli
The board can be found at
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355
We continue to make positive progress. There are 92 tickets [1] that remain
open at this time. We opened 4 tickets in the last 7 days and closed 16
(including 3 of the 4 new tickets). We also added two ti
If it encourages more and higher quality test writing +1 (nb). Also, low
risk given it’s a test dep.
Using QuickTheories as an example, merging it with a new or updated test
could be a good way to get it merged
Jordan
On Tue, Mar 10, 2020 at 10:33 AM Benjamin Lerer
wrote:
> +1
>
> On Tue, Mar
Hi Everyone!
One day late again but here is the weekly status update. Link to JIRA
board:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&projectKey=CASSANDRA
We opened 3 new tickets last week and closed 13 including 1 of the new
tickets. The current open count is 98 (reminder
Hi Everyone,
The board can be found here:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355
[Tickets That Need Attention]
A reminder that Josh has added a new 'Needs Attention' filter to show any
tasks that are stalled, need an assignee or need a reviewer. Makes it easy
if you w
+1 (nb) to the change and +1 (nb) to updating the docs to reflect this.
Jordan
On Wed, Apr 8, 2020 at 11:30 AM wrote:
> +1
>
> > El 8 abr 2020, a las 19:05, e.dimitr...@gmail.com escribió:
> >
> > +1
> >
> > Sent from my iPhone
> >
> >> On 8 Apr 2020, at 13:50, Joshua McKenzie wrote:
> >>
> >
ent from my iPhone
>
> > On 7 Apr 2020, at 20:04, Manish G wrote:
> >
> > Hi,
> >
> > Can there be a filter like 'good first issue' which new people can use to
> > find issues to start with?
> >
> > Manish
> >
> >> On Tue, Apr 7
On Thu, Apr 9, 2020 at 7:30 AM Alexandre Dutra
wrote:
> * Java drivers 3.9.0 and 4.6.0 will be released in the next few weeks.
> They will include
> support for missing features (transient replication and
> now-in-seconds), effectively
> providing complete support for protocol v5 in its current s
+1 (non-binding)
Thanks to all those who ran the tests and checks!
Jordan
On Mon, Apr 13, 2020 at 6:02 PM Sumanth Pasupuleti <
sumanth.pasupuleti...@gmail.com> wrote:
> +1 (non-binding)
>
> All java8 UTs, jvmdtests and dtests pass
>
> https://circleci.com/workflow-run/d7b3f62d-c9ad-43d6-9152-26
+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 ano
*raises hand*
- Jordan
On Thu, May 7, 2020 at 11:29 AM Mick Semb Wever wrote:
> 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 stag
Hi Everyone,
This week's status update is below but we (Josh, Jon M, and myself) thought
it was important for us all to take a closer look at which parts of the
release cycle we've assigned different tickets to so we can get a better
idea of how close we truly are to releasing beta1 and what work
On Wed, May 27, 2020 at 1:23 PM Joshua McKenzie
wrote:
> Maybe. Do we just time box, say we're going to cut an RC and give it 4
> weeks, if nothing awful surfaces we GA?
>
I've seen that work well in the past on other projects. I agree with the
notion that RCs are real candidates for release if
> On Wed, May 27, 2020 at 5:13 PM Ekaterina Dimitrova <
> ekaterina.dimitr...@datastax.com> wrote:
> - No flaky tests according to Jenkins or CircleCI? Also, some people run
> > the free tier, others take advantage of premium CircleCI. What should be
> > the framework?
While I agree that we shou
Hi Everyone,
[Board]
The board can be found here:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355
[New Tickets]
In the last 7 days we have opened 7 new tickets and closed 1. 2 were in
Alpha (including the one that was closed) and the remaining were assigned
to Beta. Please rem
Glad to see the PMC has been discussing these topics and is making efforts
towards improving on the status quo. Thanks for sharing the draft. I'll
leave more detailed questions/comments on the doc itself but as a whole its
encouraging to see the PMC rely more heavily on the community and make an
ef
cation: for
low-risk patches like test fixes, etc it may be too strong and for high
risk patches the caveat that the author can be a reviewer if also a
committer is too weak.
I'll start with those 4 to limit the potential branching of this thread.
Jordan
On Thu, Jun 4, 2020 at 12:06 PM Jorda
+1 nb
On Tue, Jun 16, 2020 at 5:45 PM Jake Luciani wrote:
> +1
>
> On Tue, Jun 16, 2020 at 5:37 PM Benedict Elliott Smith <
> bened...@apache.org>
> wrote:
>
> > +1
> >
> > On 16/06/2020, 22:23, "Nate McCall" wrote:
> >
> > +1 (binding)
> >
> > On Wed, Jun 17, 2020 at 4:19 AM Joshua Mc
+1 (nb)
On Sat, Jun 20, 2020 at 11:13 AM Jonathan Ellis wrote:
> +1
>
> On Sat, Jun 20, 2020 at 10:12 AM Joshua McKenzie
> wrote:
>
> > Link to doc:
> >
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> >
> > Change since previous cancelled vote:
On Wed, Jun 24, 2020 at 3:43 PM Dinesh Joshi wrote:
> 3. Discussion #3 - "... 1 business day notice period." Whose business day
> is it? US? Europe? Australia? NZ? We are a distributed community and so 1
> business day is ambiguous. ASF typically states a 48-72 hour period which
> gives enough t
Thanks for bringing this up Josh. I think the last time we all discussed
this on the mailing list was during the initial freeze thread where we
agreed "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
On Fri, Jun 26, 2020 at 2:58 PM Benedict Elliott Smith
wrote:
> > Nothing is stopping us for discussing CEPs now, and nothing prevents
> folks from making their own feature branches.
>
> I disagree. CEPs are just as - if not more - of a distraction than
> branching.
>
> Work doesn't happen in a
Thanks for bringing this up Jon! My current thinking is we should
officially support both 8 and 11. That increases the surface area we need
to test but I think its hard to predict what different users will run given
the current transition in the Java landscape.
Jordan
On Mon, Jul 13, 2020 at 11:4
+1 nb
On Thu, Jul 16, 2020 at 9:38 AM Yifan Cai wrote:
> +1 nb
>
>
> From: Robert Stupp
> Sent: Thursday, July 16, 2020 2:59:34 AM
> To: dev@cassandra.apache.org
> Subject: Re: [VOTE] Release Apache Cassandra 4.0-beta1
>
> +1 (nb)
>
> —
> Robert Stupp
> @snazy
It wasn't directly regarding removing support but we did reach out to
cassandra-users@ for testing 4.0 on Windows and got no response:
https://www.mail-archive.com/user@cassandra.apache.org/msg60234.html
Jordan
On Mon, Aug 10, 2020 at 4:16 AM Benedict Elliott Smith
wrote:
> Have we considered
What sort of commitment is there to the follow-up tickets? Are the
follow-ups "make this faster" or are there specific tasks we know will
help? I'm concerned by the increase in testing run times on circle but
don't think that should prevent a good/decided upon default from merging.
Jordan
On Wed,
+1
On Tue, Sep 1, 2020 at 12:22 PM Benedict Elliott Smith
wrote:
> +1
>
>
>
> On 01/09/2020, 20:09, "Caleb Rackliffe" wrote:
>
>
>
> +1
>
>
>
> On Tue, Sep 1, 2020, 2:00 PM Jasonstack Zhao Yang <
> jasonstack.z...@gmail.com>
>
> wrote:
>
>
>
> > +1
>
> >
>
> > On Wed, 2
It still seems to me that the best use of our efforts as a community is to
come together to get a stable 4.0 out as fast as possible. It would address
the branching and freeze issues that have been raised -- neither of which
currently prevent people from "scratching an itch", maintaining a
non-offi
n
>
>
> On Fri, Sep 11, 2020 at 12:10 PM, Jordan West wrote:
>
> > It still seems to me that the best use of our efforts as a community is
> to
> > come together to get a stable 4.0 out as fast as possible. It would
> address
> > the branching and freeze issu
+1
On Wed, Sep 16, 2020 at 10:29 AM sankalp kohli
wrote:
> +1
>
> On Wed, Sep 16, 2020 at 10:07 AM Ekaterina Dimitrova <
> e.dimitr...@gmail.com>
> wrote:
>
> > +1 (non-binding)
> >
> > On Wed, 16 Sep 2020 at 12:52, Dinesh Joshi wrote:
> >
> > > +1
> > >
> > >
> > >
> > > Dinesh
> > >
> > >
> >
https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle was
voted on after and under GA states: "A new branch is created for the
release with the new major version, limiting any new feature addition to
the new release branch, with new feature development will continue to
happen only
The intention was the former. It was discussed during apache con in 2019
and many people expressed the desire to wait until GA. Even some who
initially were opposed to the freeze.
Jordan
On Thu, Sep 24, 2020 at 9:04 AM Joshua McKenzie
wrote:
>
> https://lists.apache.org/thread.html/5ee66f3986b
On Thu, Sep 24, 2020 at 10:19 AM Joshua McKenzie
wrote:
> Jordan: thanks for providing that context - it's quite helpful. Was that
> aspect of the conversation captured and shared with the rest of the project
> on the mailing list? It's a shame if not, since that may have contributed
> quite a bi
+1
On Thu, Oct 8, 2020 at 7:25 AM Brandon Williams wrote:
> +1
>
> On Thu, Oct 8, 2020 at 3:20 AM Oleksandr Petrov
> wrote:
> >
> > Proposing the test build of in-jvm dtest API 0.0.6 for release.
> >
> > Repository:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=sh
Congrats Paulo!
Jordan
On Tue, Feb 9, 2021 at 10:25 PM Berenguer Blasi
wrote:
> Congrats Paulo! well done.
>
> On 9/2/21 21:28, Lorina Poland wrote:
> > Congratulations Paulo!
> > Lorina Poland
> > e. lor...@datastax.com
> > w. www.datastax.com
> >
> >
> >
> > On Tue, Feb 9, 2021 at 10:30 AM An
Congrats Joey!
Jordan
On Fri, Jul 26, 2024 at 09:22 Maxim Muzafarov wrote:
> My congratulations Joseph Lynch!
>
> On Thu, 25 Jul 2024 at 18:15, Paulo Motta wrote:
> >
> > Congratulations Joey!
> >
> > On Thu, 25 Jul 2024 at 00:55 Venkata Hari Krishna Nukala <
> n.v.harikrishna.apa...@gmail.com
If there is a quick fix for the interface issue as Alex is describing then
I am all for it. I think binary compatibility isn’t required here so the
compile time compat would be good enough.
Otherwise I tend to agree that while it should be considered a public
interface we haven’t had a strict defi
I would make the case that loss of availability / significant performance
issue, regardless of the amount of time it has existed for, is worth fixing
on the branches that are widely deployed by the community. Especially when
weighed against a loosely defined public interface issue.
The queuing iss
Generally no disagreement but more of a curiosity: what’s the motivation
for removal? Just that it’s not needed? Otherwise it’s relatively cheap and
DDL aren’t high throughput (or at least shouldn’t be since we can only deal
with so many tables)
Jordan
On Tue, Jul 30, 2024 at 15:04 Caleb Rackliff
point of creation. I'd liken it to what we did w/ some
> no-longer-relevant options for the batch commit log.
>
> On Tue, Jul 30, 2024 at 5:19 PM Jordan West wrote:
>
>> Generally no disagreement but more of a curiosity: what’s the motivation
>> for removal? Just that it’s
Oof this is a tough one. I agree with both of you on the concerns. I don’t
have good answers but I do see a few options:
- upgrade to 1.10.0 (optionally and w rigorous testing ofc) and then start
to think of a deprecation plan for LZ4 in project. That would be
unfortunate but we could probably do
I lean towards the documentation approach vs complicating the
implementation.
For me personally: I regularly use shell commands to operate on snapshots.
That includes listing them. I probably should use nodetool for it all
instead though.
Jordan
On Fri, Aug 9, 2024 at 08:09 Štefan Miklošovič
wr
+1
btw, I validated the tarball release super quickly using easy-cass-lab (
https://github.com/rustyrazorblade/easy-cass-lab). Steps I took:
1. modified cassandra_versions.yaml to point the 4.1 version at the new
release tarball of 4.1.6
2. built the image: bin/easy-cass-lab build-image (got a cof
+1, validated again with easy-cass-lab
On Thu, Aug 22, 2024 at 6:48 AM 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 l
Awesome! Congratulations Doug!
On Fri, Aug 23, 2024 at 12:17 Štefan Miklošovič
wrote:
> Great news! Congratulations, Doug.
>
> On Fri, Aug 23, 2024 at 8:55 PM Dinesh Joshi wrote:
>
>> The Apache Cassandra PMC is thrilled to announce that Doug Rohrer has
>> accepted the invitation to become a co
Thanks all!!!
On Sat, Aug 31, 2024 at 07:55 J. D. Jordan
wrote:
> Two great additions to the PMC. Congratulations to you both!
>
> -Jeremiah Jordan
>
> > On Aug 30, 2024, at 3:21 PM, Jon Haddad wrote:
> >
> >
> > The PMC's members are please
+1 to Scott’s comments. Once you expose those YAML config params outside of
a single node which many of us do, this becomes an RCE attack vector.
Something more structured as Scott proposes, similar to snapshots, would be
preferred. Would recommend a CEP.
Jordan
On Fri, Aug 30, 2024 at 20:58 C. S
I’m +1 on enabling rejection by default on all branches. We have been bit
by silent data loss (due to other bugs like the schema issues in 4.1) from
lack of rejection on several occasions and short of writing extremely
specialized tooling its unrecoverable. While both lack of availability and
data
I think folks not losing sleep over this are only in that position because
they don’t know it’s happening. Like Brandon said, ignorance is bliss (but
it’s a false bliss).
Very few users do the work necessary to detect data loss outside the
obvious paths. I agree with Caleb, if we log and give them
gt;> simply be alerting the operator to something that has already gone very
>> wrong that they may not be in any position to ever address.
>>
>> On Sep 12, 2024, at 12:44 PM, Jordan West wrote:
>>
>>
>> I’m +1 on enabling rejection by default on all branches
Congrats, welcome!
On Thu, Sep 12, 2024 at 13:16 Dinesh Joshi wrote:
> Congratulations, everyone!
>
> On Thu, Sep 12, 2024 at 4:40 AM Mick Semb Wever wrote:
>
>> The PMC's members are pleased to announce that Chris Bannister, James
>> Hartig, Jackson Flemming and João Reis have accepted invitat
Thanks for the sleuthing Stefan! This definitely is a bit unfortunate. It
sounds like a replacement is not really practical so I'll ignore that
option for now, until a viable alternative is proposed. I am -1 on us
writing our own without strong, strong justification -- primarily because I
think the
+1 nb. Very excited to see the project reach this milestone. Congrats
everyone and thank you all for the effort and hard work!
Jordan
On Tue, Mar 30, 2021 at 8:33 AM Scott Andreas wrote:
> +1 nb.
>
> This is a huge milestone for the project.
>
>
> From:
I have yet to see a legal reason why including binaries in packages is a
bad thing. I’ve read the thread and the documents linked. In fact, it looks
like it’s done specifically to avoid legal issues with copy left licenses.
It’s very common for Apache to hold on to past policies at the expense of
i
Congrats Caleb!
Jordan
On Fri, May 14, 2021 at 10:43 AM Scott Andreas wrote:
> Congratulations, Caleb!
>
> — Scott
>
> > On May 14, 2021, at 10:29 AM, Andrés de la Peña <
> a.penya.gar...@gmail.com> wrote:
> >
> > Congrats Caleb, well deserved! :)
> >
> >> On Fri, 14 May 2021 at 17:53, Paulo M
Congratulations Dinesh!
Jordan
On Thu, Jun 3, 2021 at 1:40 AM Mick Semb Wever wrote:
> Congrats Dinesh. Thanks for all the help given and offered whenever it is
> needed!
>
> On Wed, 2 Jun 2021 at 18:16, Benjamin Lerer wrote:
>
> > The PMC's members are pleased to announce that Dinesh Joshi h
The bug reported in CASSANDRA-16735 [1] was known to cause corruption
thought to be recoverable but can, in fact, induce *non-recoverable*
corruption in some partitions. If you are not yet on 3.0.23, 3.0.24,
3.11.9, or 3.11.10, it is recommended you wait to upgrade until the
Cassandra community rel
1 - 100 of 106 matches
Mail list logo
