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 people are still on 3.11 and we should not make their life harder when they consider upgrading directly to 5.0. Though clear rules for that would help the users and us. thanks, - - -- --- ----- -------- ------------- Jacek Lewandowski wt., 14 mar 2023 o 15:36 C. Scott Andreas <sc...@paradoxica.net> napisał(a): > 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 backup of each cluster to object > storage prior to upgrading from 4.x to 5.x; or to enumerate the contents of > all snapshots from an incremental backup series to ensure that no m*-series > SSTables were present prior to upgrading. > > If one failed to take on the work to do so, incremental backup snapshots > would not be restorable to a 5.x cluster if an m*-series SSTable were > present. > > – Scott > > On Mar 14, 2023, at 4:38 AM, Aleksey Yeshchenko <alek...@apple.com> wrote: > > > 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 affected > 4. Removing code comes with risk > 5. There are third-party tools that I know of which benefit from a single > C* jar that can read all relevant stable versions, and relevant here > includes 3.0 ones > > Removing a little of battle-tested reliable code and a tinier amount of > complexity is not, to me, a benefit enough to justify intentionally > breaking perfectly good and useful functionality. > > Oh, to add to that - if an operator wishes to upgrade from 3.0 to 5.0, and > we don’t support it directly, I think most of us are fine with the > requirement to go through a 4.X release first. But it’s one thing to > require a two rolling restarts (3.0 to 4.0, 4.0 to 5.0), it’s another to > require the operator to upgrade every single m* sstable to n*. Especially > when we have perfectly working code to read those. That’s incredibly > wasteful. > > AY > > On 13 Mar 2023, at 22:54, Mick Semb Wever <m...@apache.org> wrote: > > 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 such older sstable format between nodes. This > compatibility-break impacts only node-local and/or offline. > > Some arguments raised to keep m* sstable formats are: > - offline cluster upgrade, e.g. direct from 3.x to 5.0, > - single-invocation sstableupgrade usage > - third-party tools based on the above > > Personally I am not in favour of keeping, or recommending users use, > code we don't test. > > An _example_ of the code that can be cleaned up is in the patch > attached to the ticket: > CASSANDRA-18312 – Drop support for sstable formats before `na` > > What do you think? > > > > > > >
