On Fri, Mar 17, 2023 at 2:38 PM Mick Semb Wever wrote:
> So is there appetite for such a patch to fail or warn (guardrail?) to prevent
> a node running on a new version that does not support sstable formats
> existing on other nodes?
I think this makes sense, whatever the mechanism.
On Fri, 17 Mar 2023 at 17:24, Brandon Williams wrote:
> On Fri, Mar 17, 2023 at 9:25 AM Mick Semb Wever wrote:
> > Question/Suggestion: should we improve gossip to include what the oldest
> format a node has, and ensure newer versioned node joining fail/warn if it
> does > not support that
> we (including me) have done a lot of stupid shit over the years on this
> project. Half the time “this is how we’ve historically done X” to me is a
> strong argument to start doing things differently.
Oof. The truth (when applied to myself) hurts doesn't it? :)
> I suggest we should have a
> As for precedent - we (including me) have done a lot of stupid shit over the
> years on this project. Half the time “this is how we’ve historically done X”
> to me is a strong argument to start doing things differently. This is one
> such case.
+1. I definitely agree that this is one area
On Fri, Mar 17, 2023 at 9:25 AM Mick Semb Wever wrote:
> Question/Suggestion: should we improve gossip to include what the oldest
> format a node has, and ensure newer versioned node joining fail/warn if it
> does > not support that older format? That is, should we give a clear signal
> back
> Saying that there is never any complexity and we should keep formats in
> perpetuity, and I'm sitting here having a heart attack, srsly.
Nobody is claiming that. Don’t let a straw man give you a heart attack.
> Though I _always_ recommend users upgrade all sstables, before and after
> every
Ok ok, there's a number of strong arguments to keep sstable formats around
for much longer than the previous major Cassandra version, I will unset
fixVersion on 18312 :-)
Taking a look at the history of sstable formats. They were first introduced
in version 0.7, and minor versions introduced in
It's always seemed a little odd to me that we drop all the "read old format"
code given how little maintenance that code takes over time. The ability to
have a C* node read older format SSTables into perpetuity *seems* like a pretty
compelling usability feature to me (for some of the reasons
On Mon, Mar 13, 2023 at 5:54 PM Mick Semb Wever wrote:
> Personally I am not in favour of keeping, or recommending users use,
> code we don't test.
How much effort would it be to have some simple smoke tests? I think
we should make sure nothing gets indirectly broken if we're going to
keep it
I’m not sure we have an explicit rule at the moment. Would probably based on
calendar time in addition to release versions if we had one.
Addressing these on case by case basis for now is fine IMO.
I’d say the general principle should be treat extended compatibility (between
releases in
Hi,
Do we consider it as an occasional exception to the rule or we will define
a rule which explicitly says how many versions the user can expect to be
supported?
I'm slightly towards keeping the support for Mx versions just because the
time gap between 3.11 and 4.0 was very long. I suppose many
Agreed. I also think it is worthwhile to keep that code around. Given how
widespread C* 3.x use is, I do not think it is worthwhile dropping support for
those sstable formats at this time.
-Jeremiah
> On Mar 14, 2023, at 9:36 AM, C. Scott Andreas wrote:
>
>
> I agree with Aleksey's view
I agree with Aleksey's view here.To expand on the final point he makes re: requiring
SSTables be fully rewritten prior to rev'ing from 4.x to 5.x (if the cluster previously ran
3.x) –This would also invalidate incremental backups. Operators would either be required to
perform a full snapshot
Raising messaging service minimum, I have a less strong opinion on, but on
dropping m* sstable code I’m strongly -1.
1. This is code on a rarely touched path
2. It’s very stable and battle tested at this point
3. Removing it doesn’t reduce much complexity at all, just a few branches are
If we do not recommend and do not test direct upgrades from 3.x to
5.x, we can clean up a fair bit by removing code related to sstable
formats m*, as Cassandra versions 4.x and 5.0 are all on sstable
formats n*.
We don't allow mixed-version streaming, so it's not possible today to
stream any
15 matches
Mail list logo
