Re: Supporting 2.2 -> 5.0 upgrades

From a disk format point of view the only thing I remember was the disk type bug with UDTs. Bringing that logic back was hard as the type system (in 5.0) tries to avoid allowing construction of invalid states, and we would need to weaken that in order to enable the migration. Assuming the user

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

A structured, disciplined approach to graduating something from [Optional] -> [Default] makes sense to me, similar to how we're talking about a structured flow of [Preview] -> [Beta] -> [GA]. Having those clear stages gives us a framework to define what requirements of stage transitions would be

2024 year in review

It's been a long time since I sent out a status update. Let's round up 2024, and let's see if we can't have more regular updates in 2025 shall we? First, some vanity metrics on the year in review: Community Health and Activity: - Tickets created: 840 - Tickets fixed: 518 - Tickets created in 20

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

Thanks for bringing up this topic, Josh. Outside of the major features (ie. MV/SAI/TCM/Accord), one related discussion in this topic is: how can we "promote" small improvements in existing features from optional to default ? It makes sense to have optimizations launched behind a feature flag init

Re: [DISCUSS] 5.1 should be 6.0

I think there is a danger that when in comes to the next upgrade cycle there could be production clusters still running in CASSANDRA_4 mode, as the operators haven’t realised they need to move through the SCM levels. The default setting for a new cluster is CASSANDRA_4 and unless a new operator

Re: [DISCUSS] 5.1 should be 6.0

My point is that the upgrade to 5.1/6.0 isn't really complete until the CMS is initialised and this can't be done while running with SCM CASSANDRA_4 because of the messaging service limitation. Until that point, schema changes & node replacements are not supported which affects how long a bake t

Re: [DISCUSS] 5.1 should be 6.0

On Wed, Dec 11, 2024 at 7:22 AM Sam Tunnicliffe wrote: > > so running in any SCM mode for a prolonged period is not really viable. This is what many users want to do though, upgrade one DC and let it bake to see how it goes before continuing. I don't think that's unreasonable, but from working o

Re: [DISCUSS] 5.1 should be 6.0

At present, there is one version specific mode - CASSANDRA_4. Fully utilising SCM during an upgrade though requires first a "soft" upgrade into CASSANDRA_4 mode, then a full cluster bounce into UPGRADING mode and finally another into NONE. I think that as the list of versions we want to provide

Re: [DISCUSS] 5.1 should be 6.0

It might not be too bad if done selectively? I agree that would be infeasible for each patch. How many SCM modes do we have? I worry more about developer burden. It sounds like we have a balancing act with SCM complexity versus upgrade complexity. I think at the very least we should require th

Re: Supporting 2.2 -> 5.0 upgrades

I think 3.11 supported upgrade from 2.2, but I haven’t checked. I am fairly sure 4.x supported upgrade from 3.0.x also. > On 11 Dec 2024, at 12:53, Miklosovic, Stefan via dev > wrote: > > I see. That makes sense. I think that by 3.x you meant basically the latest > 3.11, right? I guess 2.2

Re: Supporting 2.2 -> 5.0 upgrades

I see. That makes sense. I think that by 3.x you meant basically the latest 3.11, right? I guess 2.2 -> 3.0 already works, we would just try to support 2.2 -> 3.11 straight away. I need to check where we are at in that area. From: Benedict Sent: Wednesda

Re: [DISCUSS] 5.1 should be 6.0

Staying slightly off topic - we'd also have to run upgrade tests for all these upgrade combinations, including different storage compatibility mode settings, that is going to be very expensive. /Marcus On Wed, Dec 11, 2024 at 12:36:02PM GMT, Sam Tunnicliffe wrote: > Maybe this is not the right

Re: [DISCUSS] 5.1 should be 6.0

Maybe this is not the right place to bring up practicalities, but the more upgrade paths we support the more complexity we take on. The ongoing issues mentioned in CASSANDRA-20118 are illustrative and the introduction of Storage Compatibility Mode adds further dimensions and operational complexi

Re: Supporting 2.2 -> 5.0 upgrades

2.2 is particularly hard because of the major storage format changes that took place. I think if we want to retain (restore) upgrade support from 3.x I would support that, but 2.x is probably too burdensome and likely to have too many hard edges. I think if users only had to upgrade 2.2->3.x th

Supporting 2.2 -> 5.0 upgrades

Hey, I want to fork the thread where we are mentioning that 2.2 -> 5.0 would be cool to support. I was involved in checking that offline upgrades from 3.0 to 5.0 work and fixed few issues along the way (1), hence I can imagine that supporting 2.2 -> 5.0 would be basically the same thing just o

Re: [DISCUSS] 5.1 should be 6.0

+1 for calling it 6, even if just to bring up to people on 2.x,3.x that they are on "ancient" code. Sent via Superhuman iOS On Wed, Dec 11 2024 at 5:23 AM, Aleksey Yeshchenko wrote: > We don’t really practice canonic sermver, we never really have, a

Re: [DISCUSS] 5.1 should be 6.0

We don’t really practice canonic sermver, we never really have, and it’s impossible to properly follow anyway. Should be perfectly fine to bump to 6.0, so long as we don’t take the bump as a license to break compatibility in a way that we wouldn’t have for 5.1. > On 11 Dec 2024, at 00:11, Jon

Re: Re-evaluate compaction defaults in 5.1/trunk

Predefined configurations make most sense to me too. My personal preference is to use a variation of the mechanism for defining memtable configurations , where the details of each are laid out explicitly in the yaml, and the s