You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Alex Petrov <al...@coffeenco.de> on 2026/02/24 08:16:41 UTC
[DISCUSS] CEP-60: Flexible Placements
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
Re: [DISCUSS] CEP-60: Flexible Placements
Posted by Štefan Miklošovič <sm...@apache.org>.
Great! Thank you for these details. I have to say your CEP is very
thorough and a lot of effort went into it which I definitely
appreciate.
Regards
On Tue, Mar 10, 2026 at 1:40 PM Alex Petrov <al...@coffeenco.de> wrote:
>
> 1) according to the section called "Project plan", you have divided
> this into "phases". What "phase" this CEP is considered to be
> production-ready and what Cassandra release do you plan to do it in?
>
>
> Each phase can be an independent deliverable, and our intention is to keep committing them to trunk and making them available right away. Of course, we can keep it all in a feature branch and keep rebasing it, but I do not see a good reason to do that. In cases where multiple patches would constitute a logical addition, we will make sure to keep them in a feature branch and commit together.
>
> 2) What is the risk of you abandoning this CEP in the middle?
>
>
> I cannot recall any precedent for CEPs being abandoned, particularly recently, and I do not see any risk of that.
>
> There has always been a push for delivering CEPs in smaller increments from the community, and this is what we're intending to do here. Each commit is an independent improvement. Even if work were to be stopped midway, we would simply get a bunch of improvements. But I do not see any risk of stopping midway.
>
> 3) You are using the language in your CEP as "we will do", "we will
> allow". Who exactly is "we" in this case? Is this CEP going to be a
> one-man show only and if not, who is going to work on this? Maybe a
> silly question, but I am just genuinely interested in knowing who is
> going to be dealing with this.
>
>
> I cannot recall any other CEP getting a question about resourcing, and unfortunately I cannot go into details of resourcing. Main goal of a CEP is to socialize a high-level design, which I believe we have done here.
>
> Regarding timelines, the best answer is "between 6.0 and 7.0". I will do my best to keep the community with timeline updates and changes. If anyone has questions about progress at any time during the project, I will be happy to address them and give updates.
>
> This CEP seems to be pretty complicated, from a high-level point of view at least. I think the
> relative lack of the questions you received on this CEP might mean
> that people just do not know what to ask.
>
>
> Good news is that I already have a working proof-of-concept, which is why I was able to go deep into a lot of detail. I see no risk of delivery, especially given the heaviest lifting was done by TCM. I did my best to evaluate all potential risks while writing a CEP, and I currently do not see any big unknowns.
>
> --Alex
>
> On Tue, Mar 10, 2026, at 9:35 AM, Štefan Miklošovič wrote:
>
> Hi Alex,
>
> 1) according to the section called "Project plan", you have divided
> this into "phases". What "phase" this CEP is considered to be
> production-ready and what Cassandra release do you plan to do it in?
>
> 2) What is the risk of you abandoning this CEP in the middle?
>
> 3) You are using the language in your CEP as "we will do", "we will
> allow". Who exactly is "we" in this case? Is this CEP going to be a
> one-man show only and if not, who is going to work on this? Maybe a
> silly question, but I am just genuinely interested in knowing who is
> going to be dealing with this. This CEP seems to be pretty
> complicated, from a high-level point of view at least. I think the
> relative lack of the questions you received on this CEP might mean
> that people just do not know what to ask.
>
> 4) Do you also plan to document what you did so we present this CEP to
> users in some digestible way or are they supposed to read the source
> code and your CEP only in order to be productive?
>
> Regards
>
> On Tue, Feb 24, 2026 at 9:18 AM Alex Petrov <al...@coffeenco.de> 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
>
>
Re: [DISCUSS] CEP-60: Flexible Placements
Posted by Josh McKenzie <jm...@apache.org>.
> What "phase" this CEP is considered to be production-ready and what Cassandra release do you plan to do it in?
>
> 2) What is the risk of you abandoning this CEP in the middle?
>
> <snip> Is this CEP going to be a one-man show only and if not, who is going to work on this?
OSS == volunteer. It's done when it's done (to reiterate my position from another thread) - at "worst" something would be merged right before a GA branch is cut and you have 3 months of runway before a GA release comes out with a feature.
If a CEP gets abandoned in the middle, that's only a "problem" if it gets merged to trunk before it's completed. Plus, if we keep to:
1. New features being optional / experimental and disabled by default
2. New features being modularized and distinct in the codebase from the rest of the existing code behind clear API / modular boundaries
Then I think we should be insulated as a project from people coming and going and work getting picked up or dropped. Worst case it never merges, or if something is merged and then abandoned before it stabilizes and promoted to GA ready, we remove it right?
On Tue, Mar 10, 2026, at 8:38 AM, Alex Petrov wrote:
>> 1) according to the section called "Project plan", you have divided
>> this into "phases". What "phase" this CEP is considered to be
>> production-ready and what Cassandra release do you plan to do it in?
>
> Each phase can be an independent deliverable, and our intention is to keep committing them to trunk and making them available right away. Of course, we can keep it all in a feature branch and keep rebasing it, but I do not see a good reason to do that. In cases where multiple patches would constitute a logical addition, we will make sure to keep them in a feature branch and commit together.
>
>> 2) What is the risk of you abandoning this CEP in the middle?
>
> I cannot recall any precedent for CEPs being abandoned, particularly recently, and I do not see any risk of that.
>
> There has always been a push for delivering CEPs in smaller increments from the community, and this is what we're intending to do here. Each commit is an independent improvement. Even if work were to be stopped midway, we would simply get a bunch of improvements. But I do not see any risk of stopping midway.
>
>> 3) You are using the language in your CEP as "we will do", "we will
>> allow". Who exactly is "we" in this case? Is this CEP going to be a
>> one-man show only and if not, who is going to work on this? Maybe a
>> silly question, but I am just genuinely interested in knowing who is
>> going to be dealing with this.
>
> I cannot recall any other CEP getting a question about resourcing, and unfortunately I cannot go into details of resourcing. Main goal of a CEP is to socialize a high-level design, which I believe we have done here.
>
> Regarding timelines, the best answer is "between 6.0 and 7.0". I will do my best to keep the community with timeline updates and changes. If anyone has questions about progress at any time during the project, I will be happy to address them and give updates.
>
>> This CEP seems to be pretty complicated, from a high-level point of view at least. I think the
>> relative lack of the questions you received on this CEP might mean
>> that people just do not know what to ask.
>
> Good news is that I already have a working proof-of-concept, which is why I was able to go deep into a lot of detail. I see no risk of delivery, especially given the heaviest lifting was done by TCM. I did my best to evaluate all potential risks while writing a CEP, and I currently do not see any big unknowns.
>
> --Alex
>
> On Tue, Mar 10, 2026, at 9:35 AM, Štefan Miklošovič wrote:
>> Hi Alex,
>>
>> 1) according to the section called "Project plan", you have divided
>> this into "phases". What "phase" this CEP is considered to be
>> production-ready and what Cassandra release do you plan to do it in?
>>
>> 2) What is the risk of you abandoning this CEP in the middle?
>>
>> 3) You are using the language in your CEP as "we will do", "we will
>> allow". Who exactly is "we" in this case? Is this CEP going to be a
>> one-man show only and if not, who is going to work on this? Maybe a
>> silly question, but I am just genuinely interested in knowing who is
>> going to be dealing with this. This CEP seems to be pretty
>> complicated, from a high-level point of view at least. I think the
>> relative lack of the questions you received on this CEP might mean
>> that people just do not know what to ask.
>>
>> 4) Do you also plan to document what you did so we present this CEP to
>> users in some digestible way or are they supposed to read the source
>> code and your CEP only in order to be productive?
>>
>> Regards
>>
>> On Tue, Feb 24, 2026 at 9:18 AM Alex Petrov <al...@coffeenco.de> 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
>>
>
Re: [DISCUSS] CEP-60: Flexible Placements
Posted by Alex Petrov <al...@coffeenco.de>.
> 1) according to the section called "Project plan", you have divided
> this into "phases". What "phase" this CEP is considered to be
> production-ready and what Cassandra release do you plan to do it in?
Each phase can be an independent deliverable, and our intention is to keep committing them to trunk and making them available right away. Of course, we can keep it all in a feature branch and keep rebasing it, but I do not see a good reason to do that. In cases where multiple patches would constitute a logical addition, we will make sure to keep them in a feature branch and commit together.
> 2) What is the risk of you abandoning this CEP in the middle?
I cannot recall any precedent for CEPs being abandoned, particularly recently, and I do not see any risk of that.
There has always been a push for delivering CEPs in smaller increments from the community, and this is what we're intending to do here. Each commit is an independent improvement. Even if work were to be stopped midway, we would simply get a bunch of improvements. But I do not see any risk of stopping midway.
> 3) You are using the language in your CEP as "we will do", "we will
> allow". Who exactly is "we" in this case? Is this CEP going to be a
> one-man show only and if not, who is going to work on this? Maybe a
> silly question, but I am just genuinely interested in knowing who is
> going to be dealing with this.
I cannot recall any other CEP getting a question about resourcing, and unfortunately I cannot go into details of resourcing. Main goal of a CEP is to socialize a high-level design, which I believe we have done here.
Regarding timelines, the best answer is "between 6.0 and 7.0". I will do my best to keep the community with timeline updates and changes. If anyone has questions about progress at any time during the project, I will be happy to address them and give updates.
> This CEP seems to be pretty complicated, from a high-level point of view at least. I think the
> relative lack of the questions you received on this CEP might mean
> that people just do not know what to ask.
Good news is that I already have a working proof-of-concept, which is why I was able to go deep into a lot of detail. I see no risk of delivery, especially given the heaviest lifting was done by TCM. I did my best to evaluate all potential risks while writing a CEP, and I currently do not see any big unknowns.
--Alex
On Tue, Mar 10, 2026, at 9:35 AM, Štefan Miklošovič wrote:
> Hi Alex,
>
> 1) according to the section called "Project plan", you have divided
> this into "phases". What "phase" this CEP is considered to be
> production-ready and what Cassandra release do you plan to do it in?
>
> 2) What is the risk of you abandoning this CEP in the middle?
>
> 3) You are using the language in your CEP as "we will do", "we will
> allow". Who exactly is "we" in this case? Is this CEP going to be a
> one-man show only and if not, who is going to work on this? Maybe a
> silly question, but I am just genuinely interested in knowing who is
> going to be dealing with this. This CEP seems to be pretty
> complicated, from a high-level point of view at least. I think the
> relative lack of the questions you received on this CEP might mean
> that people just do not know what to ask.
>
> 4) Do you also plan to document what you did so we present this CEP to
> users in some digestible way or are they supposed to read the source
> code and your CEP only in order to be productive?
>
> Regards
>
> On Tue, Feb 24, 2026 at 9:18 AM Alex Petrov <al...@coffeenco.de> 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
>
Re: [DISCUSS] CEP-60: Flexible Placements
Posted by Štefan Miklošovič <sm...@apache.org>.
Hi Alex,
1) according to the section called "Project plan", you have divided
this into "phases". What "phase" this CEP is considered to be
production-ready and what Cassandra release do you plan to do it in?
2) What is the risk of you abandoning this CEP in the middle?
3) You are using the language in your CEP as "we will do", "we will
allow". Who exactly is "we" in this case? Is this CEP going to be a
one-man show only and if not, who is going to work on this? Maybe a
silly question, but I am just genuinely interested in knowing who is
going to be dealing with this. This CEP seems to be pretty
complicated, from a high-level point of view at least. I think the
relative lack of the questions you received on this CEP might mean
that people just do not know what to ask.
4) Do you also plan to document what you did so we present this CEP to
users in some digestible way or are they supposed to read the source
code and your CEP only in order to be productive?
Regards
On Tue, Feb 24, 2026 at 9:18 AM Alex Petrov <al...@coffeenco.de> 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
Re: [DISCUSS] CEP-60: Flexible Placements
Posted by Patrick McFadin <pm...@gmail.com>.
I sense another definitive guide in our future. 😂
The more I think about the operations aspects I can see plenty of places
for use case guidance. Which seems like the right place to tackle this as
it gets closer to a release. UCS is a good example of that.
On Tue, Mar 10, 2026 at 3:29 AM Alex Petrov <al...@coffeenco.de> wrote:
> Several more quotes that intersect between CEP-57 and CEP-60:
>
> from CEP-57:
> > To treat this problem we should allow users to specify a table’s
> atomicity level, for example `partition`, `row` or `none`, and prevent
> splitting inside the specified level.
>
> While implementing flexible placements, we intend to allow tables
> belonging to the same keyspace to have ranges that are split between the
> nodes differently. Our understanding that this aligns well with CEP-57,
> since every table will likely have different partitions with hotspots in
> different places. CEP-60 will allow making split points at any point in the
> table, and things like repair and streaming for such split tables will just
> work out of the box.
>
> > Implementing a, or improving the existing, mechanisms of collecting load
> statistics to form the input of automatic redistribution of data.
>
> There definitely will be some intersection here, since we are going to be
> collecting subrange metrics for load. CEP-60 does not include
> change-in-load-triggered automatic redistribution, since our intention was
> to limit the scope of CEP, but our ultimate goal does include
> auto-balancing. I have a separate document describing all metrics we'll be
> adding in detail. It was not included to CEP for scope reasons, but I will
> make sure to loop in CEP-57 authors once we start working on this.
>
> On Mon, Mar 9, 2026, at 11:54 PM, Alex Petrov wrote:
>
> Great question!
>
> If one decides to enable tablets and use default flexible placement
> mechanism/algorithm, it will pick the best possible fit for the tablet. Of
> course one can always override this or pick a custom tablet placement
> algorithm.
>
> Tokens won’t become less pronounced for things like routing, streaming, or
> repair. The only place where this CEP moves from tokens will be the concept
> of a node owning a token and token ring derived replication.
>
> For simplicity I suppose it might be easier to say “repair tablet X” or
> “replace replica Y in tablet Z”, etc. But then, tablet is just a
> replicated range.
>
> On Mon, Mar 9, 2026, at 11:31 PM, Patrick McFadin wrote:
>
>
> Thanks, that helps.
>
> I agree that if tokens remain the underlying range coordinate system, then
> CEP-57 is not immediately inconsistent with CEP-60.
>
> My question is about operators and migrations(my favorite topic). As
> clusters move from classic token-derived placements to flexible placements,
> should operators continue to think in token-bounded ranges, or do tokens
> become mostly an internal detail, and the operational model shift to
> tablets or table-specific placement units?
>
> Patrick
>
>
> On Mon, Mar 9, 2026 at 2:37 PM Alex Petrov <al...@coffeenco.de> wrote:
>
>
> In short, CEP-60 doesn’t suggest we’re moving away from tokens. It adds an
> optional opportunity to allow placements to be decoupled from token
> ownership. In other words, owned range will still have start and end
> tokens, so I don’t see any inconsistency here.
>
> I’d also like to highlight that anyone who prefers token ownership as a
> way of generation of placement maps, this will still be possible, and there
> are no plans or intentions for deprecating this.
>
> Does this clarify relation to CEP-57 for you?
>
>
> On Mon, Mar 9, 2026, at 10:09 PM, Patrick McFadin wrote:
>
>
> 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 <al...@coffeenco.de> 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 <al...@coffeenco.de> 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
>
>
>
>
>
>
Re: [DISCUSS] CEP-60: Flexible Placements
Posted by Alex Petrov <al...@coffeenco.de>.
Several more quotes that intersect between CEP-57 and CEP-60:
from CEP-57:
> To treat this problem we should allow users to specify a table’s atomicity level, for example `partition`, `row` or `none`, and prevent splitting inside the specified level.
While implementing flexible placements, we intend to allow tables belonging to the same keyspace to have ranges that are split between the nodes differently. Our understanding that this aligns well with CEP-57, since every table will likely have different partitions with hotspots in different places. CEP-60 will allow making split points at any point in the table, and things like repair and streaming for such split tables will just work out of the box.
> Implementing a, or improving the existing, mechanisms of collecting load statistics to form the input of automatic redistribution of data.
There definitely will be some intersection here, since we are going to be collecting subrange metrics for load. CEP-60 does not include change-in-load-triggered automatic redistribution, since our intention was to limit the scope of CEP, but our ultimate goal does include auto-balancing. I have a separate document describing all metrics we'll be adding in detail. It was not included to CEP for scope reasons, but I will make sure to loop in CEP-57 authors once we start working on this.
On Mon, Mar 9, 2026, at 11:54 PM, Alex Petrov wrote:
> Great question!
>
> If one decides to enable tablets and use default flexible placement mechanism/algorithm, it will pick the best possible fit for the tablet. Of course one can always override this or pick a custom tablet placement algorithm.
>
> Tokens won’t become less pronounced for things like routing, streaming, or repair. The only place where this CEP moves from tokens will be the concept of a node owning a token and token ring derived replication.
>
> For simplicity I suppose it might be easier to say “repair tablet X” or “replace replica Y in tablet Z”, etc. But then, tablet is just a replicated range.
>
> On Mon, Mar 9, 2026, at 11:31 PM, Patrick McFadin wrote:
>>
>> Thanks, that helps.
>>
>> I agree that if tokens remain the underlying range coordinate system, then CEP-57 is not immediately inconsistent with CEP-60.
>>
>> My question is about operators and migrations(my favorite topic). As clusters move from classic token-derived placements to flexible placements, should operators continue to think in token-bounded ranges, or do tokens become mostly an internal detail, and the operational model shift to tablets or table-specific placement units?
>>
>> Patrick
>>
>>
>>
>> On Mon, Mar 9, 2026 at 2:37 PM Alex Petrov <al...@coffeenco.de> wrote:
>>> __
>>> In short, CEP-60 doesn’t suggest we’re moving away from tokens. It adds an optional opportunity to allow placements to be decoupled from token ownership. In other words, owned range will still have start and end tokens, so I don’t see any inconsistency here.
>>>
>>> I’d also like to highlight that anyone who prefers token ownership as a way of generation of placement maps, this will still be possible, and there are no plans or intentions for deprecating this.
>>>
>>> Does this clarify relation to CEP-57 for you?
>>>
>>>
>>> On Mon, Mar 9, 2026, at 10:09 PM, Patrick McFadin wrote:
>>>>
>>>> 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 <al...@coffeenco.de> 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 <al...@coffeenco.de> 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
>>>>>
>>>
>
Re: [DISCUSS] CEP-60: Flexible Placements
Posted by Alex Petrov <al...@coffeenco.de>.
Great question!
If one decides to enable tablets and use default flexible placement mechanism/algorithm, it will pick the best possible fit for the tablet. Of course one can always override this or pick a custom tablet placement algorithm.
Tokens won’t become less pronounced for things like routing, streaming, or repair. The only place where this CEP moves from tokens will be the concept of a node owning a token and token ring derived replication.
For simplicity I suppose it might be easier to say “repair tablet X” or “replace replica Y in tablet Z”, etc. But then, tablet is just a replicated range.
On Mon, Mar 9, 2026, at 11:31 PM, Patrick McFadin wrote:
>
> Thanks, that helps.
>
> I agree that if tokens remain the underlying range coordinate system, then CEP-57 is not immediately inconsistent with CEP-60.
>
> My question is about operators and migrations(my favorite topic). As clusters move from classic token-derived placements to flexible placements, should operators continue to think in token-bounded ranges, or do tokens become mostly an internal detail, and the operational model shift to tablets or table-specific placement units?
>
> Patrick
>
>
>
> On Mon, Mar 9, 2026 at 2:37 PM Alex Petrov <al...@coffeenco.de> wrote:
>> __
>> In short, CEP-60 doesn’t suggest we’re moving away from tokens. It adds an optional opportunity to allow placements to be decoupled from token ownership. In other words, owned range will still have start and end tokens, so I don’t see any inconsistency here.
>>
>> I’d also like to highlight that anyone who prefers token ownership as a way of generation of placement maps, this will still be possible, and there are no plans or intentions for deprecating this.
>>
>> Does this clarify relation to CEP-57 for you?
>>
>>
>> On Mon, Mar 9, 2026, at 10:09 PM, Patrick McFadin wrote:
>>>
>>> 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 <al...@coffeenco.de> 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 <al...@coffeenco.de> 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
>>>>
>>
Re: [DISCUSS] CEP-60: Flexible Placements
Posted by Patrick McFadin <pm...@gmail.com>.
Thanks, that helps.
I agree that if tokens remain the underlying range coordinate system, then
CEP-57 is not immediately inconsistent with CEP-60.
My question is about operators and migrations(my favorite topic). As
clusters move from classic token-derived placements to flexible placements,
should operators continue to think in token-bounded ranges, or do tokens
become mostly an internal detail, and the operational model shift to
tablets or table-specific placement units?
Patrick
On Mon, Mar 9, 2026 at 2:37 PM Alex Petrov <al...@coffeenco.de> wrote:
> In short, CEP-60 doesn’t suggest we’re moving away from tokens. It adds an
> optional opportunity to allow placements to be decoupled from token
> ownership. In other words, owned range will still have start and end
> tokens, so I don’t see any inconsistency here.
>
> I’d also like to highlight that anyone who prefers token ownership as a
> way of generation of placement maps, this will still be possible, and there
> are no plans or intentions for deprecating this.
>
> Does this clarify relation to CEP-57 for you?
>
>
> On Mon, Mar 9, 2026, at 10:09 PM, Patrick McFadin wrote:
>
>
> 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 <al...@coffeenco.de> 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 <al...@coffeenco.de> 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
>
>
>
>
Re: [DISCUSS] CEP-60: Flexible Placements
Posted by Alex Petrov <al...@coffeenco.de>.
In short, CEP-60 doesn’t suggest we’re moving away from tokens. It adds an optional opportunity to allow placements to be decoupled from token ownership. In other words, owned range will still have start and end tokens, so I don’t see any inconsistency here.
I’d also like to highlight that anyone who prefers token ownership as a way of generation of placement maps, this will still be possible, and there are no plans or intentions for deprecating this.
Does this clarify relation to CEP-57 for you?
On Mon, Mar 9, 2026, at 10:09 PM, Patrick McFadin wrote:
>
> 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 <al...@coffeenco.de> 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 <al...@coffeenco.de> 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
>>
Re: [DISCUSS] CEP-60: Flexible Placements
Posted by Patrick McFadin <pm...@gmail.com>.
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 <al...@coffeenco.de> 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 <al...@coffeenco.de> 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
>
>
>
Re: [DISCUSS] CEP-60: Flexible Placements
Posted by Alex Petrov <al...@coffeenco.de>.
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 <al...@coffeenco.de> 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
Re: [DISCUSS] CEP-60: Flexible Placements
Posted by Jon Haddad <jo...@rustyrazorblade.com>.
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 <al...@coffeenco.de> 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
>