I do, actually. I finally got my head around CEP-60 and wanted to ask about an inconsistency. Your proposal is trying to move away from tokens, but CEP-57 requires them. From CEP-57:
the key should be constructed as: ByteComparable.sequence(Token(X, Y), Serialization(X, Y), A, B, C) How is this going to be reconciled? Stay on tokens or change CEP-57? Patrick On Sat, Mar 7, 2026 at 4:54 AM Alex Petrov <[email protected]> wrote: > Thanks Jon! Very excited to be working on this. > > Since there has been not much discussion, and from conversations with some > folks on slack and elsewhere it seems like we might be ready to move this > to a vote. > > I will hold it off until Monday in case someone else had any thoughts. > > > > On Tue, Feb 24, 2026, at 10:57 PM, Jon Haddad wrote: > > Alex, > > 12 years ago I filed CASSANDRA-8494 hoping someone much smarter than me > would take on the Herculean effort of completely reworking how we manage > our data. This CEP addresses my wish for incremental bootstrap and also > incorporates tablets, which have been on my radar for a long time. This > work will address some of Cassandra's biggest pain points today for > operators. > Thank you so much for this. I cannot overstate my enthusiasm for this > CEP!! > > Jon > > > On Tue, Feb 24, 2026 at 12:17 AM Alex Petrov <[email protected]> wrote: > > > Hi everyone, > > We'd like to propose CEP-60: Flexible Placements [1] for adoption by the > community. Building on CEP-21's Transactional Cluster Metadata [2], CEP-60 > enables incremental, resumable operations, improved cluster density, and > flexibility of data placements / ownership. > > CEP-60 benefits all users by further improving reliability of ownership > operations. With flexible placements, clusters maintain near-optimal load > balance at any size without explicit rebalancing phases. Ownership changes > are broken into smaller sub-range steps that benefit from zero-copy > streaming. > > CEP-60 is designed for incremental delivery: range-aware compaction, > routing key abstractions, and metrics collection are useful on their own > and will ship independently of the flexible placements feature. Existing > token-based and vnode clusters will continue to work (while benefitting > from incremental ops), and flexible placements can be enabled (and later > disabled, if ever needed) on a per-keyspace basis. > > The CEP is linked here: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-60:+Flexible+Placements > > Looking forward to the discussion of this CEP here on the dev list. > > Thanks! > > [1] > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-60:+Flexible+Placements > [2] > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata > > >
