I want to ask about this ticket in particular, I know I am somehow
hijacking this thread but taking recent discussion into account where we
kind of rejected the idea of using TCM log for storing configuration, what
does this mean for tickets like this? Is this still viable or we need to
completely
I think you’re making the mistake of assuming a representative sample of the
community participates in these debates. Sensibly, a majority of the community
sits these out, and I think on this topic that’s actually the rational response.
That doesn’t stop folk voting for something else when the d
Josh - from a community / user perspective, I think what you just described
is a win. I have no clue what it means in the context of the actual work
that needs to be done, so I'll leave that aspect to others to comment on.
I could see a world where a 5.1 makes sense - but only if it was offering
My opinion is that it would be valuable to take this discussion as a forcing
function to determine how we plan to handle releases broadly to answer the "5.1
should be 6.0" question. Assuming we move away from ad hoc per-release debate.
If there's broad strong dissent (i.e. let's have 6.0 be the
On Jan 29, 2025 at 3:32:13 PM, Josh McKenzie wrote:
> My opinion is that it would be valuable to take this discussion as a
> forcing function to determine how we plan to handle releases broadly to
> answer the "5.1 should be 6.0" question. Assuming we move away from ad hoc
> per-release debate. I
This got way off topic from 5.1 should be 6.0, so maybe there should be a
new DISCUSS thread with the correct title to have a discussion around
codifying our upgrade paths?
FWIW this mostly agrees with my thoughts around upgrade support.
T-2 online upgrade supported, T-1 API compatible, deprecat
> Jira actually does that and creates a diagram,
Yes, I am aware about this functionality, unfortunately it does not show
the most interesting part: conditions/expectations for transitions
I have combined the following summary based on comments from Benedict, the
docs and a discussion with Stefan:
Hi everyone,
A couple of years ago, I organized a Cassandra Forward event to get
people excited about the next version of Cassandra. It's time to ramp
up the excitement about one of the more consequential releases of
Cassandra: 5.1 or 6. Whatever we land on as a version will impact the
community w
This is a real problem that David points to. Anything that affects query execution needs to be deterministic for Accord to produce the same outcome on all nodes. If one node refuses to execute a write and another doesn’t they will behave inconsistently.There are other ways around this though, such
I've let this topic sit in my head overnight and kind of chewed on it. While I
agree w/the "we're doing what matches our unspoken incentives" angle Benedict,
I think we can do better than that both for ourselves and our users if we apply
energy here and codify something. If people come out with
Using TCM to distribute this information across the cluster vs. using some
other LWT-ish distributed CP solution higher in the stack should effectively
have the same UX guarantees to us and our users right? So I think it's still
quite viable, even if we're just LWT'ing things into distributed ta
> Using TCM to distribute this information across the cluster vs. using
some other LWT-ish distributed CP solution higher in the stack should
effectively have the same UX guarantees to us and our users right? So I
think it's still quite viable, even if we're just LWT'ing things into
distributed ta
Patch available means the PR is ready for review.Needs committer means we think it’s ready to merge but we need at least one more committer +1 (and maybe one to actually merge).There’s a requirement that at least one contributor reviews a patch. There’s a separate a requirement that two committers
On Wed, Jan 29, 2025 at 10:26 AM Dmitry Konstantinov wrote:
> I want to draw it explicitly (as a diagram or as a table) and share to check
> my understanding, then after a discussion it can be integrated in the
> contributor docs.
> I hope it makes sense..
Jira actually does that and creates a
To be explicit about my concerns in the previous comments…
TCM vs new table, I don’t care too much. I prefer TCM over new table, but its
a preference
My comment before were more about the UX of global configs. As long as we
“could” (maybe per config, not every config likely needs this) allow
One motivating case for TCM vs non-TCM… When accord processes the user request,
we can make sure to use the configs as they were at the execution epoch… by
splitting this out it makes all configs non-deterministic from Accord’s point
of view…
Simple example, lets say you add a global config th
> Simple example, lets say you add a global config that says you can’t
write more than X bytes, when this is outside of TCM accord can have
multiple different values while executing the query (assuming a user
changed it)…
Couldn’t we have an eventually consistent barrier, so that a new
configurati
To clarify, when I say unspoken it includes "not consciously considered but
shapes engagement patterns". I don't think there's people sitting around deeply
against either the status quo or my proposal who are holding back for nefarious
purposes or anything.
And yeah - my goal is to try and put
Hi all,
I have used Cassandra for a long time and had my fork to make changes but
recently I have started to contribute more actively to the upstream.
As a quite a new contributor I am a bit confused with a lack of clarity for
ticket transition rules. I understand that for the majority there is no
19 matches
Mail list logo
