Re: [DISCUSS] Change the useage of nodetool tablehistograms

[guo Maxwell]

According to the conclusion, I think we can fix the bug when the argument
number is bigger than  2 first.

Thanks everyone.

Bowen Song via dev  于2023年3月23日周四 22:17写道：

> In that case, I would recommend fix the bug that prints everything when an
> arbitrary number of arguments is given.
> On 23/03/2023 13:40, guo Maxwell wrote:
>
> firstly I think anything existing must be reasonable，so ignore option for
> tablestats must be a need for the user to use. at least I used it some time
> ；
> secondly in order  to keep this as simple as possible ，I think left the
> option unchanged is enough ，because the original usage is simple enough.
> user can just print the specified table after set nodetool tablehistorgrams
> ks table ，and if there is ten tables in kesypace  ，it is simple for him to
> type ten times with different table names which I think at first Only set
> with argument ks keyspace name is enough.
> When we just want to see eight tables in the ks ，the user should just type
> eight table name which ignore two table may be enough.
>
>
>
>
> Bowen Song via dev 于2023年3月23日 周四下午8:07写道：
>
>> I don't think the nodetool tablestats command's parameters should be
>> used as a reference implementation for the nodetool tablehistograms
>> command. Because:
>>
>>- the tablehistograms command can take the keyspace and table as two
>>separate parameters, but the tablestats command can't.
>>- the tablestats command can take keyspace (without table) as a
>>parameter, but the tablehistograms command can't.
>>
>> The introduction of the -ks and -tbs options are unnecessary for the
>> tablestats command, because it's parameters are:
>>
>> nodetool tablestats [| [> table>| [...]]]
>>
>> Which means any positional parameter without a dot is treated as a
>> keyspace name, otherwise it's treated as dot-separated keyspace and table
>> name. That, however, does not apply to the nodetool tablehistograms
>> command, which led to your workaround - the addition of the -ks and -tbs
>> options.
>>
>> But if you could just forget about the nodetool tablestats command for a
>> moment, and look at the nodetool tablehistograms command alone, you will
>> see that it's unnecessary to introduce the -ks and -tbs options, because
>> the command already takes keyspace name and table name, just in a different
>> format.
>>
>> In addition to that, I would be interested to know how often do people
>> use the -i option in the nodetool tablestats command. My best guess is,
>> very very rarely.
>>
>> If my guess is correct, we should keep the nodetool tablehistograms
>> command as simple as:
>>
>> nodetool tablehistograms [  [ [...]] |
>>  [ [...]]]
>>
>> It's good enough if the above can cover the majority of use cases. The
>> remaining use cases can be dealt with individually, by multiple invocations
>> of the same command or providing it with a script-generated list of tables
>> in the  format.
>>
>> TL;DR: The KISS principle 
>> should apply here - keep it simple.
>>
>>
>> On 23/03/2023 03:05, guo Maxwell wrote:
>>
>> Maybe I didn't describe the usage of option "-i" clearly, The reason why
>> I think the command argument should be like this :
>>
>>
>> 1. nodetool tablehistograms ks.tb1 or ks tb1  ... //this is *one of the
>>> old way *of using tablehistogram. will print out the histograms of
>>> tabke ks.tb1 , we keep the old format to print out the table
>>> histograms,besides if more than two arguments is provied, suchu as nodetool
>>> tablehistograms system.local system_schema.columns system_schema.tables
>>> then all tables's  histograms will be printed out (I think this is a
>>> bug that not as excepted in the document's decription, we should remind the
>>> user that this is an incorrenct usage)
>>>
>>> 2. nodetool tablehistograms -tbs ks.tb1 ks.tb2  //print out list of
>>> tables' histograms with format keyspace.table
>>> 3.nodetool tablehistograms -ks ks1 ks2 ks3 ... //print out list of
>>> keyspaces histograms
>>> 4.nodetool tablehistograms -i -ks ks1 ks2  //print out list of table
>>> histograms except for the keyspaces list behind the option -i
>>> 5.nodetool tablehistograns -i -tbs ks.tb1 ks.tb2 // print out list
>>> tables' histograms except for table in ks.tb1 ks.tb2
>>> 6.nodetool tablehistograns -i -tbs ks.tb1 ks.tb2 -ks ks1 // print out
>>> list tables' histograms except for table in ks.tb1 ks.tb2 and all
>>> tables in ks1
>>> 6.none option specified ,then all tables histograms will be print out.// 
>>> this
>>> is *another one of the old way* of using tablehistogram.
>>>
>>
>>  is to make the command format  to be consistent with the format of
>> nodetool tablestats, so for users, there will be a unified awareness of
>> using these two commands, rather than different commands requiring
>> different usage awareness , we can see the description of the tablestats
>> doc for option "-i "
>>
>> Ignore the list of tables and display the remaining tables
>>>
>>
>> that

Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Mick Semb Wever]

The TCM work (CEP-21) is in its review stage but being well past our
cut-off date¹ for merging, and now jeopardising 5.0 GA efforts, I would
like to propose the following.

We merge TCM and Accord only to trunk.  Then branch cassandra-5.1 and cut
an immediate 5.1-alpha1 release.

I see this as a win-win scenario for us, considering our current situation.
 (Though it is unfortunate that Accord is included in this scenario because
we agreed it to be based upon TCM.)

This will mean…
 - We get to focus on getting 5.0 to beta and GA, which already has a ton
of features users want.
 - We get an alpha release with TCM and Accord into users hands quickly for
broader testing and feedback.
 - We isolate GA efforts on TCM and Accord – giving oss and downstream
engineers time and patience reviewing and testing.  TCM will be the biggest
patch ever to land in C*.
 - Give users a choice for a more incremental upgrade approach, given just
how many new features we're putting on them in one year.
 - 5.1 w/ TCM and Accord will maintain its upgrade compatibility with all
4.x versions, just as if it had landed in 5.0.


The risks/costs this introduces are
 - If we cannot stabilise TCM and/or Accord on the cassandra-5.1 branch,
and at some point decide to undo this work, while we can throw away the
cassandra-5.1 branch we would need to do a bit of work reverting the
changes in trunk.  This is a _very_ edge case, as confidence levels on the
design and implementation of both are already tested and high.
 - We will have to maintain an additional branch.  I propose that we treat
the 5.1 branch in the same maintenance window as 5.0 (like we have with 3.0
and 3.11).  This also adds the merge path overhead.
 - Reviewing of TCM and Accord will continue to happen post-merge.  This is
not our normal practice, but this work will have already received its
two +1s from committers, and such ongoing review effort is akin to GA
stabilisation work on release branches.


I see no other ok solution in front of us that gets us at least both the
5.0 beta and TCM+Accord alpha releases this year.  Keeping in mind users
demand to start experimenting with these features, and our Cassandra Summit
in December.


1) https://lists.apache.org/thread/9c5cnn57c7oqw8wzo3zs0dkrm4f17lm3

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Benedict]

I’m cool with this.

We may have to think about numbering as I think TCM will break some backwards 
compatibility and we might technically expect the follow-up release to be 6.0

Maybe it’s not so bad to have such rapid releases either way.

> On 23 Oct 2023, at 12:52, Mick Semb Wever  wrote:
> 
> 
> 
> The TCM work (CEP-21) is in its review stage but being well past our cut-off 
> date¹ for merging, and now jeopardising 5.0 GA efforts, I would like to 
> propose the following.
> 
> We merge TCM and Accord only to trunk.  Then branch cassandra-5.1 and cut an 
> immediate 5.1-alpha1 release.
> 
> I see this as a win-win scenario for us, considering our current situation.  
> (Though it is unfortunate that Accord is included in this scenario because we 
> agreed it to be based upon TCM.)
> 
> This will mean…
>  - We get to focus on getting 5.0 to beta and GA, which already has a ton of 
> features users want.
>  - We get an alpha release with TCM and Accord into users hands quickly for 
> broader testing and feedback.
>  - We isolate GA efforts on TCM and Accord – giving oss and downstream 
> engineers time and patience reviewing and testing.  TCM will be the biggest 
> patch ever to land in C*.
>  - Give users a choice for a more incremental upgrade approach, given just 
> how many new features we're putting on them in one year.
>  - 5.1 w/ TCM and Accord will maintain its upgrade compatibility with all 4.x 
> versions, just as if it had landed in 5.0.
> 
> 
> The risks/costs this introduces are
>  - If we cannot stabilise TCM and/or Accord on the cassandra-5.1 branch, and 
> at some point decide to undo this work, while we can throw away the 
> cassandra-5.1 branch we would need to do a bit of work reverting the changes 
> in trunk.  This is a _very_ edge case, as confidence levels on the design and 
> implementation of both are already tested and high.
>  - We will have to maintain an additional branch.  I propose that we treat 
> the 5.1 branch in the same maintenance window as 5.0 (like we have with 3.0 
> and 3.11).  This also adds the merge path overhead.
>  - Reviewing of TCM and Accord will continue to happen post-merge.  This is 
> not our normal practice, but this work will have already received its two +1s 
> from committers, and such ongoing review effort is akin to GA stabilisation 
> work on release branches.
> 
> 
> I see no other ok solution in front of us that gets us at least both the 5.0 
> beta and TCM+Accord alpha releases this year.  Keeping in mind users demand 
> to start experimenting with these features, and our Cassandra Summit in 
> December.
> 
> 
> 1) https://lists.apache.org/thread/9c5cnn57c7oqw8wzo3zs0dkrm4f17lm3
> 
> 

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Sam Tunnicliffe]

+1 from me too. 

Regarding Benedict's point, backwards incompatibility should be minimal; we 
modified snitch behaviour slightly, so that local snitch config only relates to 
the local node, all peer info is fetched from cluster metadata. There is also a 
minor change to the way failed bootstraps are handled, as with TCM they require 
an explicit cancellation step (running a nodetool command). 

Whether consensus decrees that this constitutes a major bump or not, I think 
decoupling these major projects from 5.0 is the right move. 
 

> On 23 Oct 2023, at 12:57, Benedict  wrote:
> 
> I’m cool with this.
> 
> We may have to think about numbering as I think TCM will break some backwards 
> compatibility and we might technically expect the follow-up release to be 6.0
> 
> Maybe it’s not so bad to have such rapid releases either way.
> 
>> On 23 Oct 2023, at 12:52, Mick Semb Wever  wrote:
>> 
>> 
>> 
>> The TCM work (CEP-21) is in its review stage but being well past our cut-off 
>> date¹ for merging, and now jeopardising 5.0 GA efforts, I would like to 
>> propose the following.
>> 
>> We merge TCM and Accord only to trunk.  Then branch cassandra-5.1 and cut an 
>> immediate 5.1-alpha1 release.
>> 
>> I see this as a win-win scenario for us, considering our current situation.  
>> (Though it is unfortunate that Accord is included in this scenario because 
>> we agreed it to be based upon TCM.)
>> 
>> This will mean…
>>  - We get to focus on getting 5.0 to beta and GA, which already has a ton of 
>> features users want.
>>  - We get an alpha release with TCM and Accord into users hands quickly for 
>> broader testing and feedback.
>>  - We isolate GA efforts on TCM and Accord – giving oss and downstream 
>> engineers time and patience reviewing and testing.  TCM will be the biggest 
>> patch ever to land in C*.
>>  - Give users a choice for a more incremental upgrade approach, given just 
>> how many new features we're putting on them in one year.
>>  - 5.1 w/ TCM and Accord will maintain its upgrade compatibility with all 
>> 4.x versions, just as if it had landed in 5.0.
>> 
>> 
>> The risks/costs this introduces are
>>  - If we cannot stabilise TCM and/or Accord on the cassandra-5.1 branch, and 
>> at some point decide to undo this work, while we can throw away the 
>> cassandra-5.1 branch we would need to do a bit of work reverting the changes 
>> in trunk.  This is a _very_ edge case, as confidence levels on the design 
>> and implementation of both are already tested and high.
>>  - We will have to maintain an additional branch.  I propose that we treat 
>> the 5.1 branch in the same maintenance window as 5.0 (like we have with 3.0 
>> and 3.11).  This also adds the merge path overhead.
>>  - Reviewing of TCM and Accord will continue to happen post-merge.  This is 
>> not our normal practice, but this work will have already received its two 
>> +1s from committers, and such ongoing review effort is akin to GA 
>> stabilisation work on release branches.
>> 
>> 
>> I see no other ok solution in front of us that gets us at least both the 5.0 
>> beta and TCM+Accord alpha releases this year.  Keeping in mind users demand 
>> to start experimenting with these features, and our Cassandra Summit in 
>> December.
>> 
>> 
>> 1) https://lists.apache.org/thread/9c5cnn57c7oqw8wzo3zs0dkrm4f17lm3
>> 
>> 

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Patrick McFadin]

I'm really surprised to see this email. The last I heard everything was on
track for getting into 5.0 and TBH and Accord is what a majority of users
are expecting in 5.0. And how could this be a .1 release?

What is it going to take to get it into 5.0? What is off track and how did
we get here?

On Mon, Oct 23, 2023 at 6:51 AM Sam Tunnicliffe  wrote:

> +1 from me too.
>
> Regarding Benedict's point, backwards incompatibility should be minimal;
> we modified snitch behaviour slightly, so that local snitch config only
> relates to the local node, all peer info is fetched from cluster metadata.
> There is also a minor change to the way failed bootstraps are handled, as
> with TCM they require an explicit cancellation step (running a nodetool
> command).
>
> Whether consensus decrees that this constitutes a major bump or not, I
> think decoupling these major projects from 5.0 is the right move.
>
>
> On 23 Oct 2023, at 12:57, Benedict  wrote:
>
> I’m cool with this.
>
> We may have to think about numbering as I think TCM will break some
> backwards compatibility and we might technically expect the follow-up
> release to be 6.0
>
> Maybe it’s not so bad to have such rapid releases either way.
>
> On 23 Oct 2023, at 12:52, Mick Semb Wever  wrote:
>
> 
>
> The TCM work (CEP-21) is in its review stage but being well past our
> cut-off date¹ for merging, and now jeopardising 5.0 GA efforts, I would
> like to propose the following.
>
> We merge TCM and Accord only to trunk.  Then branch cassandra-5.1 and cut
> an immediate 5.1-alpha1 release.
>
> I see this as a win-win scenario for us, considering our current
> situation.  (Though it is unfortunate that Accord is included in this
> scenario because we agreed it to be based upon TCM.)
>
> This will mean…
>  - We get to focus on getting 5.0 to beta and GA, which already has a ton
> of features users want.
>  - We get an alpha release with TCM and Accord into users hands quickly
> for broader testing and feedback.
>  - We isolate GA efforts on TCM and Accord – giving oss and downstream
> engineers time and patience reviewing and testing.  TCM will be the biggest
> patch ever to land in C*.
>  - Give users a choice for a more incremental upgrade approach, given just
> how many new features we're putting on them in one year.
>  - 5.1 w/ TCM and Accord will maintain its upgrade compatibility with all
> 4.x versions, just as if it had landed in 5.0.
>
>
> The risks/costs this introduces are
>  - If we cannot stabilise TCM and/or Accord on the cassandra-5.1 branch,
> and at some point decide to undo this work, while we can throw away the
> cassandra-5.1 branch we would need to do a bit of work reverting the
> changes in trunk.  This is a _very_ edge case, as confidence levels on the
> design and implementation of both are already tested and high.
>  - We will have to maintain an additional branch.  I propose that we treat
> the 5.1 branch in the same maintenance window as 5.0 (like we have with 3.0
> and 3.11).  This also adds the merge path overhead.
>  - Reviewing of TCM and Accord will continue to happen post-merge.  This
> is not our normal practice, but this work will have already received its
> two +1s from committers, and such ongoing review effort is akin to GA
> stabilisation work on release branches.
>
>
> I see no other ok solution in front of us that gets us at least both the
> 5.0 beta and TCM+Accord alpha releases this year.  Keeping in mind users
> demand to start experimenting with these features, and our Cassandra Summit
> in December.
>
>
> 1) https://lists.apache.org/thread/9c5cnn57c7oqw8wzo3zs0dkrm4f17lm3
>
>
>
>

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Jeremiah Jordan]

 +1 from me assuming we have tickets and two committer +1’s on them for
everything being committed to trunk, and CI is working/passing before it
merges.  The usual things, but I want to make sure we do not compromise on
any of them as we try to “move fast” here.

-Jeremiah Jordan

On Oct 23, 2023 at 8:50:46 AM, Sam Tunnicliffe  wrote:

> +1 from me too.
>
> Regarding Benedict's point, backwards incompatibility should be minimal;
> we modified snitch behaviour slightly, so that local snitch config only
> relates to the local node, all peer info is fetched from cluster metadata.
> There is also a minor change to the way failed bootstraps are handled, as
> with TCM they require an explicit cancellation step (running a nodetool
> command).
>
> Whether consensus decrees that this constitutes a major bump or not, I
> think decoupling these major projects from 5.0 is the right move.
>
>
> On 23 Oct 2023, at 12:57, Benedict  wrote:
>
> I’m cool with this.
>
> We may have to think about numbering as I think TCM will break some
> backwards compatibility and we might technically expect the follow-up
> release to be 6.0
>
> Maybe it’s not so bad to have such rapid releases either way.
>
> On 23 Oct 2023, at 12:52, Mick Semb Wever  wrote:
>
> 
>
> The TCM work (CEP-21) is in its review stage but being well past our
> cut-off date¹ for merging, and now jeopardising 5.0 GA efforts, I would
> like to propose the following.
>
> We merge TCM and Accord only to trunk.  Then branch cassandra-5.1 and cut
> an immediate 5.1-alpha1 release.
>
> I see this as a win-win scenario for us, considering our current
> situation.  (Though it is unfortunate that Accord is included in this
> scenario because we agreed it to be based upon TCM.)
>
> This will mean…
>  - We get to focus on getting 5.0 to beta and GA, which already has a ton
> of features users want.
>  - We get an alpha release with TCM and Accord into users hands quickly
> for broader testing and feedback.
>  - We isolate GA efforts on TCM and Accord – giving oss and downstream
> engineers time and patience reviewing and testing.  TCM will be the biggest
> patch ever to land in C*.
>  - Give users a choice for a more incremental upgrade approach, given just
> how many new features we're putting on them in one year.
>  - 5.1 w/ TCM and Accord will maintain its upgrade compatibility with all
> 4.x versions, just as if it had landed in 5.0.
>
>
> The risks/costs this introduces are
>  - If we cannot stabilise TCM and/or Accord on the cassandra-5.1 branch,
> and at some point decide to undo this work, while we can throw away the
> cassandra-5.1 branch we would need to do a bit of work reverting the
> changes in trunk.  This is a _very_ edge case, as confidence levels on the
> design and implementation of both are already tested and high.
>  - We will have to maintain an additional branch.  I propose that we treat
> the 5.1 branch in the same maintenance window as 5.0 (like we have with 3.0
> and 3.11).  This also adds the merge path overhead.
>  - Reviewing of TCM and Accord will continue to happen post-merge.  This
> is not our normal practice, but this work will have already received its
> two +1s from committers, and such ongoing review effort is akin to GA
> stabilisation work on release branches.
>
>
> I see no other ok solution in front of us that gets us at least both the
> 5.0 beta and TCM+Accord alpha releases this year.  Keeping in mind users
> demand to start experimenting with these features, and our Cassandra Summit
> in December.
>
>
> 1) https://lists.apache.org/thread/9c5cnn57c7oqw8wzo3zs0dkrm4f17lm3
>
>
>
>

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Patrick McFadin]

I’m going to be clearer in my statement.

This has to be in 5.0, even if it’s alpha and ships after December, or this
is going to be disaster that will take us much longer to unravel.

On Mon, Oct 23, 2023 at 7:49 AM Jeremiah Jordan 
wrote:

> +1 from me assuming we have tickets and two committer +1’s on them for
> everything being committed to trunk, and CI is working/passing before it
> merges.  The usual things, but I want to make sure we do not compromise on
> any of them as we try to “move fast” here.
>
> -Jeremiah Jordan
>
> On Oct 23, 2023 at 8:50:46 AM, Sam Tunnicliffe  wrote:
>
>> +1 from me too.
>>
>> Regarding Benedict's point, backwards incompatibility should be minimal;
>> we modified snitch behaviour slightly, so that local snitch config only
>> relates to the local node, all peer info is fetched from cluster metadata.
>> There is also a minor change to the way failed bootstraps are handled, as
>> with TCM they require an explicit cancellation step (running a nodetool
>> command).
>>
>> Whether consensus decrees that this constitutes a major bump or not, I
>> think decoupling these major projects from 5.0 is the right move.
>>
>>
>> On 23 Oct 2023, at 12:57, Benedict  wrote:
>>
>> I’m cool with this.
>>
>> We may have to think about numbering as I think TCM will break some
>> backwards compatibility and we might technically expect the follow-up
>> release to be 6.0
>>
>> Maybe it’s not so bad to have such rapid releases either way.
>>
>> On 23 Oct 2023, at 12:52, Mick Semb Wever  wrote:
>>
>> 
>>
>> The TCM work (CEP-21) is in its review stage but being well past our
>> cut-off date¹ for merging, and now jeopardising 5.0 GA efforts, I would
>> like to propose the following.
>>
>> We merge TCM and Accord only to trunk.  Then branch cassandra-5.1 and cut
>> an immediate 5.1-alpha1 release.
>>
>> I see this as a win-win scenario for us, considering our current
>> situation.  (Though it is unfortunate that Accord is included in this
>> scenario because we agreed it to be based upon TCM.)
>>
>> This will mean…
>>  - We get to focus on getting 5.0 to beta and GA, which already has a ton
>> of features users want.
>>  - We get an alpha release with TCM and Accord into users hands quickly
>> for broader testing and feedback.
>>  - We isolate GA efforts on TCM and Accord – giving oss and downstream
>> engineers time and patience reviewing and testing.  TCM will be the biggest
>> patch ever to land in C*.
>>  - Give users a choice for a more incremental upgrade approach, given
>> just how many new features we're putting on them in one year.
>>  - 5.1 w/ TCM and Accord will maintain its upgrade compatibility with all
>> 4.x versions, just as if it had landed in 5.0.
>>
>>
>> The risks/costs this introduces are
>>  - If we cannot stabilise TCM and/or Accord on the cassandra-5.1 branch,
>> and at some point decide to undo this work, while we can throw away the
>> cassandra-5.1 branch we would need to do a bit of work reverting the
>> changes in trunk.  This is a _very_ edge case, as confidence levels on the
>> design and implementation of both are already tested and high.
>>  - We will have to maintain an additional branch.  I propose that we
>> treat the 5.1 branch in the same maintenance window as 5.0 (like we have
>> with 3.0 and 3.11).  This also adds the merge path overhead.
>>  - Reviewing of TCM and Accord will continue to happen post-merge.  This
>> is not our normal practice, but this work will have already received its
>> two +1s from committers, and such ongoing review effort is akin to GA
>> stabilisation work on release branches.
>>
>>
>> I see no other ok solution in front of us that gets us at least both the
>> 5.0 beta and TCM+Accord alpha releases this year.  Keeping in mind users
>> demand to start experimenting with these features, and our Cassandra Summit
>> in December.
>>
>>
>> 1) https://lists.apache.org/thread/9c5cnn57c7oqw8wzo3zs0dkrm4f17lm3
>>
>>
>>
>>

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Paulo Motta]

>From a user perspective I have to say I was excited to see Accord/TCM being
released on 5.0 but at the same time a little nervous about seeing so many
overhauling features being shipped on the same release.

I think rushing last minute features hurts the stability goals we set for
the project. As far as I understand, we have agreed to have a "release
train" model where everything ready by the release date is shipped and
anything else slips to the next version.

5.0 will bring a number of exciting innovations and I don't think not
including TCM/Accord can be considered a disaster. I think letting the
community test the currently shipped features separately from TCM/Accord
will be a benefit from a stability perspective without hurting the project
momentum.

I think TCM/Accord are such major and long awaited improvements to the
project that deserve its own exclusive release, otherwise they can easily
shadow the other exciting features being shipped. I don't see any issue in
performing an earlier release next year if TCM/Accord is ready by then.

Regarding the versioning scheme, if we follow the versioning scheme we have
defined "by the book" then TCM/Accord would belong to a 6.0 version, which
I have to admit feels a bit weird but it would signal to the user community
that a major change is being introduced. I don't feel strongly about this
so would be fine with a 5.1 even though it would be a departure from the
new versioning scheme we have agreed upon.

On Mon, Oct 23, 2023 at 10:55 AM Patrick McFadin  wrote:

> I’m going to be clearer in my statement.
>
> This has to be in 5.0, even if it’s alpha and ships after December, or
> this is going to be disaster that will take us much longer to unravel.
>
> On Mon, Oct 23, 2023 at 7:49 AM Jeremiah Jordan 
> wrote:
>
>> +1 from me assuming we have tickets and two committer +1’s on them for
>> everything being committed to trunk, and CI is working/passing before it
>> merges.  The usual things, but I want to make sure we do not compromise on
>> any of them as we try to “move fast” here.
>>
>> -Jeremiah Jordan
>>
>> On Oct 23, 2023 at 8:50:46 AM, Sam Tunnicliffe  wrote:
>>
>>> +1 from me too.
>>>
>>> Regarding Benedict's point, backwards incompatibility should be minimal;
>>> we modified snitch behaviour slightly, so that local snitch config only
>>> relates to the local node, all peer info is fetched from cluster metadata.
>>> There is also a minor change to the way failed bootstraps are handled, as
>>> with TCM they require an explicit cancellation step (running a nodetool
>>> command).
>>>
>>> Whether consensus decrees that this constitutes a major bump or not, I
>>> think decoupling these major projects from 5.0 is the right move.
>>>
>>>
>>> On 23 Oct 2023, at 12:57, Benedict  wrote:
>>>
>>> I’m cool with this.
>>>
>>> We may have to think about numbering as I think TCM will break some
>>> backwards compatibility and we might technically expect the follow-up
>>> release to be 6.0
>>>
>>> Maybe it’s not so bad to have such rapid releases either way.
>>>
>>> On 23 Oct 2023, at 12:52, Mick Semb Wever  wrote:
>>>
>>> 
>>>
>>> The TCM work (CEP-21) is in its review stage but being well past our
>>> cut-off date¹ for merging, and now jeopardising 5.0 GA efforts, I would
>>> like to propose the following.
>>>
>>> We merge TCM and Accord only to trunk.  Then branch cassandra-5.1 and
>>> cut an immediate 5.1-alpha1 release.
>>>
>>> I see this as a win-win scenario for us, considering our current
>>> situation.  (Though it is unfortunate that Accord is included in this
>>> scenario because we agreed it to be based upon TCM.)
>>>
>>> This will mean…
>>>  - We get to focus on getting 5.0 to beta and GA, which already has a
>>> ton of features users want.
>>>  - We get an alpha release with TCM and Accord into users hands quickly
>>> for broader testing and feedback.
>>>  - We isolate GA efforts on TCM and Accord – giving oss and downstream
>>> engineers time and patience reviewing and testing.  TCM will be the biggest
>>> patch ever to land in C*.
>>>  - Give users a choice for a more incremental upgrade approach, given
>>> just how many new features we're putting on them in one year.
>>>  - 5.1 w/ TCM and Accord will maintain its upgrade compatibility with
>>> all 4.x versions, just as if it had landed in 5.0.
>>>
>>>
>>> The risks/costs this introduces are
>>>  - If we cannot stabilise TCM and/or Accord on the cassandra-5.1 branch,
>>> and at some point decide to undo this work, while we can throw away the
>>> cassandra-5.1 branch we would need to do a bit of work reverting the
>>> changes in trunk.  This is a _very_ edge case, as confidence levels on the
>>> design and implementation of both are already tested and high.
>>>  - We will have to maintain an additional branch.  I propose that we
>>> treat the 5.1 branch in the same maintenance window as 5.0 (like we have
>>> with 3.0 and 3.11).  This also adds the merge path overhead.
>>>  - Reviewing of TCM and Accord wi

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Josh McKenzie]

> This has to be in 5.0, even if it’s alpha and ships after December, or this 
> is going to be disaster that will take us much longer to unravel. 
I'm curious to hear more about this.

> What is it going to take to get it into 5.0? What is off track and how did we 
> get here?
I'm going to crystal-ball a combination of "we're in mythical man-month 
territory" and "we're doing something that's never been done before on a 
code-base that's a decade and a half old. In a distributed system. That takes 
(often unpredictable) time."

I'm +1 to what you've laid out here Mick. The idea of having another branch to 
merge through makes me sad, but it's worth it to both get 5.0 into users' hands 
around our committed cadence + also get an alpha of these new features into 
their hands as well IMO.

On Mon, Oct 23, 2023, at 11:14 AM, Paulo Motta wrote:
> From a user perspective I have to say I was excited to see Accord/TCM being 
> released on 5.0 but at the same time a little nervous about seeing so many 
> overhauling features being shipped on the same release.
> 
> I think rushing last minute features hurts the stability goals we set for the 
> project. As far as I understand, we have agreed to have a "release train" 
> model where everything ready by the release date is shipped and anything else 
> slips to the next version.
> 
> 5.0 will bring a number of exciting innovations and I don't think not 
> including TCM/Accord can be considered a disaster. I think letting the 
> community test the currently shipped features separately from TCM/Accord will 
> be a benefit from a stability perspective without hurting the project 
> momentum.
> 
> I think TCM/Accord are such major and long awaited improvements to the 
> project that deserve its own exclusive release, otherwise they can easily 
> shadow the other exciting features being shipped. I don't see any issue in 
> performing an earlier release next year if TCM/Accord is ready by then.
> 
> Regarding the versioning scheme, if we follow the versioning scheme we have 
> defined "by the book" then TCM/Accord would belong to a 6.0 version, which I 
> have to admit feels a bit weird but it would signal to the user community 
> that a major change is being introduced. I don't feel strongly about this so 
> would be fine with a 5.1 even though it would be a departure from the new 
> versioning scheme we have agreed upon.
> 
> On Mon, Oct 23, 2023 at 10:55 AM Patrick McFadin  wrote:
>> I’m going to be clearer in my statement. 
>> 
>> This has to be in 5.0, even if it’s alpha and ships after December, or this 
>> is going to be disaster that will take us much longer to unravel. 
>> 
>> On Mon, Oct 23, 2023 at 7:49 AM Jeremiah Jordan  
>> wrote:
>>> +1 from me assuming we have tickets and two committer +1’s on them for 
>>> everything being committed to trunk, and CI is working/passing before it 
>>> merges.  The usual things, but I want to make sure we do not compromise on 
>>> any of them as we try to “move fast” here.
>>> 
>>> -Jeremiah Jordan
>>> 
>>> On Oct 23, 2023 at 8:50:46 AM, Sam Tunnicliffe  wrote:
 
 +1 from me too. 
 
 Regarding Benedict's point, backwards incompatibility should be minimal; 
 we modified snitch behaviour slightly, so that local snitch config only 
 relates to the local node, all peer info is fetched from cluster metadata. 
 There is also a minor change to the way failed bootstraps are handled, as 
 with TCM they require an explicit cancellation step (running a nodetool 
 command). 
 
 Whether consensus decrees that this constitutes a major bump or not, I 
 think decoupling these major projects from 5.0 is the right move. 
  
 
> On 23 Oct 2023, at 12:57, Benedict  wrote:
> 
> 
> I’m cool with this.
> 
> We may have to think about numbering as I think TCM will break some 
> backwards compatibility and we might technically expect the follow-up 
> release to be 6.0
> 
> Maybe it’s not so bad to have such rapid releases either way.
> 
> 
>> On 23 Oct 2023, at 12:52, Mick Semb Wever  wrote:
>> 
>> 
>> The TCM work (CEP-21) is in its review stage but being well past our 
>> cut-off date¹ for merging, and now jeopardising 5.0 GA efforts, I would 
>> like to propose the following.
>> 
>> We merge TCM and Accord only to trunk.  Then branch cassandra-5.1 and 
>> cut an immediate 5.1-alpha1 release.
>> 
>> I see this as a win-win scenario for us, considering our current 
>> situation.  (Though it is unfortunate that Accord is included in this 
>> scenario because we agreed it to be based upon TCM.)
>> 
>> This will mean…
>>  - We get to focus on getting 5.0 to beta and GA, which already has a 
>> ton of features users want.
>>  - We get an alpha release with TCM and Accord into users hands quickly 
>> for broader testing and feedback.
>>  - We isolate GA efforts on TCM and A

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Mick Semb Wever]

>
> Regarding the versioning scheme, if we follow the versioning scheme we
> have defined "by the book" then TCM/Accord would belong to a 6.0 version,
> which I have to admit feels a bit weird but it would signal to the user
> community that a major change is being introduced. I don't feel strongly
> about this so would be fine with a 5.1 even though it would be a departure
> from the new versioning scheme we have agreed upon.
>


It can be 5.1 as there's no upgrade-compatibility breakages in TCM/Accord.

Sure, some like big shiny new numbers for new features and new APIs.  But
if we follow the online upgrade-compatibility approach, clusters will be
able to upgrade from any 4.x to 5.1, therefore from the operators PoV the
"6" is not required.

I had a chat with Sam offline about this.  There's a small change in how
the PropertyFileSnitch works and removing the ability to change a node's
rack/dc once joined.  It's been suggested to enforce these in 5.0 (with
simple assertions).

Aside from my desire to make our semver consistent to just
upgrade-compatibility, I'm in favour of sticking to our general messaging
the past year that Accord will be available in Cassandra 5.  (Introducing a
new major number 6 here IMHO hurts more than helps.)

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Paulo Motta]

> Sure, some like big shiny new numbers for new features and new APIs.  But
if we follow the online upgrade-compatibility approach, clusters will be
able to upgrade from any 4.x to 5.1, therefore from the operators PoV the
"6" is not required.
> Aside from my desire to make our semver consistent to just
upgrade-compatibility, I'm in favour of sticking to our general messaging
the past year that Accord will be available in Cassandra 5.  (Introducing a
new major number 6 here IMHO hurts more than helps.)

Thanks for this context and clarification. Based on this I think it makes
sense to follow an "online upgrade-compatibility approach" to define major
versioning and have TCM/Accord on 5.1.

On Mon, Oct 23, 2023 at 11:33 AM Mick Semb Wever  wrote:

> Regarding the versioning scheme, if we follow the versioning scheme we
>> have defined "by the book" then TCM/Accord would belong to a 6.0 version,
>> which I have to admit feels a bit weird but it would signal to the user
>> community that a major change is being introduced. I don't feel strongly
>> about this so would be fine with a 5.1 even though it would be a departure
>> from the new versioning scheme we have agreed upon.
>>
>
>
> It can be 5.1 as there's no upgrade-compatibility breakages in TCM/Accord.
>
> Sure, some like big shiny new numbers for new features and new APIs.  But
> if we follow the online upgrade-compatibility approach, clusters will be
> able to upgrade from any 4.x to 5.1, therefore from the operators PoV the
> "6" is not required.
>
> I had a chat with Sam offline about this.  There's a small change in how
> the PropertyFileSnitch works and removing the ability to change a node's
> rack/dc once joined.  It's been suggested to enforce these in 5.0 (with
> simple assertions).
>
> Aside from my desire to make our semver consistent to just
> upgrade-compatibility, I'm in favour of sticking to our general messaging
> the past year that Accord will be available in Cassandra 5.  (Introducing a
> new major number 6 here IMHO hurts more than helps.)
>
>

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Miklosovic, Stefan via dev]

To double check the reasoning behind this proposal:

1) is 5.1 going to contain only TCM / Accord when it comes to new features? In 
other words, 5.1, except these two, will only ever contain bugfixes from older 
branches (merging them up) or fixes for TCM / Accord itself (which will be 
eventually merged to trunk)? If that is all true, will we create 6.0 in trunk 
or trunk will be 5.2?

I think it is a nice-to-have. 5.1.0 will be just vanilla TCM / Accord on top of 
5.0.

2) Do we drop the support of 3.0 and 3.11 after 5.0.0 is out or after 5.1.0 is?

3) When I understand our current deprecation policy correctly, everything which 
is deprecated in 3.11 included and older is eligible to be removed in 5.x. If 
we manage to remove some deprecations in 5.0.0 and there are some leftovers in 
5.1, am I still OK to remove the rest in 5.1.x or do I need to wait until 6.0 
is made? (I think the answer is "yes", I can remove 3.x stuff in whatever 5.x).

Regards



From: Mick Semb Wever 
Sent: Monday, October 23, 2023 13:51
To: dev
Subject: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 
5.1-alpha1)

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.




The TCM work (CEP-21) is in its review stage but being well past our cut-off 
date¹ for merging, and now jeopardising 5.0 GA efforts, I would like to propose 
the following.

We merge TCM and Accord only to trunk.  Then branch cassandra-5.1 and cut an 
immediate 5.1-alpha1 release.

I see this as a win-win scenario for us, considering our current situation.  
(Though it is unfortunate that Accord is included in this scenario because we 
agreed it to be based upon TCM.)

This will mean…
 - We get to focus on getting 5.0 to beta and GA, which already has a ton of 
features users want.
 - We get an alpha release with TCM and Accord into users hands quickly for 
broader testing and feedback.
 - We isolate GA efforts on TCM and Accord – giving oss and downstream 
engineers time and patience reviewing and testing.  TCM will be the biggest 
patch ever to land in C*.
 - Give users a choice for a more incremental upgrade approach, given just how 
many new features we're putting on them in one year.
 - 5.1 w/ TCM and Accord will maintain its upgrade compatibility with all 4.x 
versions, just as if it had landed in 5.0.


The risks/costs this introduces are
 - If we cannot stabilise TCM and/or Accord on the cassandra-5.1 branch, and at 
some point decide to undo this work, while we can throw away the cassandra-5.1 
branch we would need to do a bit of work reverting the changes in trunk.  This 
is a _very_ edge case, as confidence levels on the design and implementation of 
both are already tested and high.
 - We will have to maintain an additional branch.  I propose that we treat the 
5.1 branch in the same maintenance window as 5.0 (like we have with 3.0 and 
3.11).  This also adds the merge path overhead.
 - Reviewing of TCM and Accord will continue to happen post-merge.  This is not 
our normal practice, but this work will have already received its two +1s from 
committers, and such ongoing review effort is akin to GA stabilisation work on 
release branches.


I see no other ok solution in front of us that gets us at least both the 5.0 
beta and TCM+Accord alpha releases this year.  Keeping in mind users demand to 
start experimenting with these features, and our Cassandra Summit in December.


1) 
https://lists.apache.org/thread/9c5cnn57c7oqw8wzo3zs0dkrm4f17lm3

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Jeff Jirsa]

On Mon, Oct 23, 2023 at 4:52 AM Mick Semb Wever  wrote:

>
> The TCM work (CEP-21) is in its review stage but being well past our
> cut-off date¹ for merging, and now jeopardising 5.0 GA efforts, I would
> like to propose the following.
>
>

I think this presumes that 5.0 GA is date driven instead of feature driven.

I'm sure there's a conversation elsewhere, but why isn't this date movable?

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Josh McKenzie]

We discussed that at length in various other mailing threads Jeff - kind of 
settled on "we're committing to cutting a major (semver MAJOR or MINOR) every 
12 months but want to remain flexible for exceptions when appropriate".

And then we discussed our timeline for 5.0 this year and settled on the "let's 
try and get it out this calendar year so it's 12 months after 4.1, but we'll 
grandfather in TCM and Accord past freeze date if they can make it by October".

So that's the history for how we landed here.

> 2) Do we drop the support of 3.0 and 3.11 after 5.0.0 is out or after 5.1.0 
> is?
This is my understanding, yes. Deprecation and support drop is predicated on 
the 5.0 release, not any specific features or anything.

On Mon, Oct 23, 2023, at 12:29 PM, Jeff Jirsa wrote:
> 
> 
> On Mon, Oct 23, 2023 at 4:52 AM Mick Semb Wever  wrote:
>> 
>> The TCM work (CEP-21) is in its review stage but being well past our cut-off 
>> date¹ for merging, and now jeopardising 5.0 GA efforts, I would like to 
>> propose the following.
>> 
> 
> 
> I think this presumes that 5.0 GA is date driven instead of feature driven.
> 
> I'm sure there's a conversation elsewhere, but why isn't this date movable?
> 
>  

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Aleksey Yeshchenko]

I’m not so sure that many folks will choose to go 4.0->5.0->5.1 path instead of 
just waiting longer for TCM+Accord to be in, and go 4.0->5.1 in one hop.

Nobody likes going through these upgrades. So I personally expect 5.0 to be a 
largely ghost release if we go this route, adopted by few, just a permanent 
burden on the merge path to trunk.

Not to say that there isn’t valuable stuff in 5.0 without TCM and Accord - 
there most certainly is - but with the expectation that 5.1 will follow up 
reasonably shortly after with all that *and* two highly anticipated features on 
top, I just don’t see the point. It will be another 2.2 release.


> On 23 Oct 2023, at 17:43, Josh McKenzie  wrote:
> 
> We discussed that at length in various other mailing threads Jeff - kind of 
> settled on "we're committing to cutting a major (semver MAJOR or MINOR) every 
> 12 months but want to remain flexible for exceptions when appropriate".
> 
> And then we discussed our timeline for 5.0 this year and settled on the 
> "let's try and get it out this calendar year so it's 12 months after 4.1, but 
> we'll grandfather in TCM and Accord past freeze date if they can make it by 
> October".
> 
> So that's the history for how we landed here.
> 
>> 2) Do we drop the support of 3.0 and 3.11 after 5.0.0 is out or after 5.1.0 
>> is?
> This is my understanding, yes. Deprecation and support drop is predicated on 
> the 5.0 release, not any specific features or anything.
> 
> On Mon, Oct 23, 2023, at 12:29 PM, Jeff Jirsa wrote:
>> 
>> 
>> On Mon, Oct 23, 2023 at 4:52 AM Mick Semb Wever > > wrote:
>> 
>> The TCM work (CEP-21) is in its review stage but being well past our cut-off 
>> date¹ for merging, and now jeopardising 5.0 GA efforts, I would like to 
>> propose the following.
>> 
>> 
>> 
>> I think this presumes that 5.0 GA is date driven instead of feature driven.
>> 
>> I'm sure there's a conversation elsewhere, but why isn't this date movable?

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Benedict]

I agree. If we go this route we should essentially announce an immediate 5.1 alpha at the same time as 5.0 GA, and I can’t see almost anybody rolling out 5.0 with 5.1 so close on its heels.On 23 Oct 2023, at 18:11, Aleksey Yeshchenko  wrote:I’m not so sure that many folks will choose to go 4.0->5.0->5.1 path instead of just waiting longer for TCM+Accord to be in, and go 4.0->5.1 in one hop.Nobody likes going through these upgrades. So I personally expect 5.0 to be a largely ghost release if we go this route, adopted by few, just a permanent burden on the merge path to trunk.Not to say that there isn’t valuable stuff in 5.0 without TCM and Accord - there most certainly is - but with the expectation that 5.1 will follow up reasonably shortly after with all that *and* two highly anticipated features on top, I just don’t see the point. It will be another 2.2 release.On 23 Oct 2023, at 17:43, Josh McKenzie  wrote:We discussed that at length in various other mailing threads Jeff - kind of settled on "we're committing to cutting a major (semver MAJOR or MINOR) every 12 months but want to remain flexible for exceptions when appropriate".And then we discussed our timeline for 5.0 this year and settled on the "let's try and get it out this calendar year so it's 12 months after 4.1, but we'll grandfather in TCM and Accord past freeze date if they can make it by October".So that's the history for how we landed here.2) Do we drop the support of 3.0 and 3.11 after 5.0.0 is out or after 5.1.0 is?This is my understanding, yes. Deprecation and support drop is predicated on the 5.0 release, not any specific features or anything.On Mon, Oct 23, 2023, at 12:29 PM, Jeff Jirsa wrote:On Mon, Oct 23, 2023 at 4:52 AM Mick Semb Wever  wrote:The TCM work (CEP-21) is in its review stage but being well past our cut-off date¹ for merging, and now jeopardising 5.0 GA efforts, I would like to propose the following.I think this presumes that 5.0 GA is date driven instead of feature driven.I'm sure there's a conversation elsewhere, but why isn't this date movable?

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Benedict]

To be clear, I’m not making an argument either way about the path forwards we should take, just concurring about a likely downside of this proposal. I don’t have a strong opinion about how we should proceed.On 23 Oct 2023, at 18:16, Benedict  wrote:I agree. If we go this route we should essentially announce an immediate 5.1 alpha at the same time as 5.0 GA, and I can’t see almost anybody rolling out 5.0 with 5.1 so close on its heels.On 23 Oct 2023, at 18:11, Aleksey Yeshchenko  wrote:I’m not so sure that many folks will choose to go 4.0->5.0->5.1 path instead of just waiting longer for TCM+Accord to be in, and go 4.0->5.1 in one hop.Nobody likes going through these upgrades. So I personally expect 5.0 to be a largely ghost release if we go this route, adopted by few, just a permanent burden on the merge path to trunk.Not to say that there isn’t valuable stuff in 5.0 without TCM and Accord - there most certainly is - but with the expectation that 5.1 will follow up reasonably shortly after with all that *and* two highly anticipated features on top, I just don’t see the point. It will be another 2.2 release.On 23 Oct 2023, at 17:43, Josh McKenzie  wrote:We discussed that at length in various other mailing threads Jeff - kind of settled on "we're committing to cutting a major (semver MAJOR or MINOR) every 12 months but want to remain flexible for exceptions when appropriate".And then we discussed our timeline for 5.0 this year and settled on the "let's try and get it out this calendar year so it's 12 months after 4.1, but we'll grandfather in TCM and Accord past freeze date if they can make it by October".So that's the history for how we landed here.2) Do we drop the support of 3.0 and 3.11 after 5.0.0 is out or after 5.1.0 is?This is my understanding, yes. Deprecation and support drop is predicated on the 5.0 release, not any specific features or anything.On Mon, Oct 23, 2023, at 12:29 PM, Jeff Jirsa wrote:On Mon, Oct 23, 2023 at 4:52 AM Mick Semb Wever  wrote:The TCM work (CEP-21) is in its review stage but being well past our cut-off date¹ for merging, and now jeopardising 5.0 GA efforts, I would like to propose the following.I think this presumes that 5.0 GA is date driven instead of feature driven.I'm sure there's a conversation elsewhere, but why isn't this date movable?

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Caleb Rackliffe]

Kind of in the same place as Benedict/Aleksey.

If we release a 5.1 in, let's say...March of next year, the number of 5.0
users is going to be very minimal. Nobody is going to upgrade anything
important from now through the first half of January anyway, right? They're
going to be making sure their existing clusters aren't exploding.

(We still want TCM/Accord to be available to people to test by Summit, but
that feels unrelated to whether we cut a 5.1 branch...)

Aside: If I had to pick a month of the year to release software used by
large enterprises, it probably would be something like March instead of
December. I have no good research to back that up, of course...

On Mon, Oct 23, 2023 at 12:19 PM Benedict  wrote:

> To be clear, I’m not making an argument either way about the path forwards
> we should take, just concurring about a likely downside of this proposal. I
> don’t have a strong opinion about how we should proceed.
>
> On 23 Oct 2023, at 18:16, Benedict  wrote:
>
> 
> I agree. If we go this route we should essentially announce an immediate
> 5.1 alpha at the same time as 5.0 GA, and I can’t see almost anybody
> rolling out 5.0 with 5.1 so close on its heels.
>
> On 23 Oct 2023, at 18:11, Aleksey Yeshchenko  wrote:
>
> I’m not so sure that many folks will choose to go 4.0->5.0->5.1 path
> instead of just waiting longer for TCM+Accord to be in, and go 4.0->5.1 in
> one hop.
>
> Nobody likes going through these upgrades. So I personally expect 5.0 to
> be a largely ghost release if we go this route, adopted by few, just a
> permanent burden on the merge path to trunk.
>
> Not to say that there isn’t valuable stuff in 5.0 without TCM and Accord -
> there most certainly is - but with the expectation that 5.1 will follow up
> reasonably shortly after with all that *and* two highly anticipated
> features on top, I just don’t see the point. It will be another 2.2 release.
>
>
> On 23 Oct 2023, at 17:43, Josh McKenzie  wrote:
>
> We discussed that at length in various other mailing threads Jeff - kind
> of settled on "we're committing to cutting a major (semver MAJOR or MINOR)
> every 12 months but want to remain flexible for exceptions when
> appropriate".
>
> And then we discussed our timeline for 5.0 this year and settled on the
> "let's try and get it out this calendar year so it's 12 months after 4.1,
> but we'll grandfather in TCM and Accord past freeze date if they can make
> it by October".
>
> So that's the history for how we landed here.
>
> 2) Do we drop the support of 3.0 and 3.11 after 5.0.0 is out or after
> 5.1.0 is?
>
> This is my understanding, yes. Deprecation and support drop is predicated
> on the 5.0 release, not any specific features or anything.
>
> On Mon, Oct 23, 2023, at 12:29 PM, Jeff Jirsa wrote:
>
>
>
> On Mon, Oct 23, 2023 at 4:52 AM Mick Semb Wever  wrote:
>
>
> The TCM work (CEP-21) is in its review stage but being well past our
> cut-off date¹ for merging, and now jeopardising 5.0 GA efforts, I would
> like to propose the following.
>
>
>
> I think this presumes that 5.0 GA is date driven instead of feature driven.
>
> I'm sure there's a conversation elsewhere, but why isn't this date movable?
>
>
>

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Caleb Rackliffe]

...or like the end of January. Either way, feel free to ignore the "aside"
:)

On Mon, Oct 23, 2023 at 12:53 PM Caleb Rackliffe 
wrote:

> Kind of in the same place as Benedict/Aleksey.
>
> If we release a 5.1 in, let's say...March of next year, the number of 5.0
> users is going to be very minimal. Nobody is going to upgrade anything
> important from now through the first half of January anyway, right? They're
> going to be making sure their existing clusters aren't exploding.
>
> (We still want TCM/Accord to be available to people to test by Summit, but
> that feels unrelated to whether we cut a 5.1 branch...)
>
> Aside: If I had to pick a month of the year to release software used by
> large enterprises, it probably would be something like March instead of
> December. I have no good research to back that up, of course...
>
> On Mon, Oct 23, 2023 at 12:19 PM Benedict  wrote:
>
>> To be clear, I’m not making an argument either way about the path
>> forwards we should take, just concurring about a likely downside of this
>> proposal. I don’t have a strong opinion about how we should proceed.
>>
>> On 23 Oct 2023, at 18:16, Benedict  wrote:
>>
>> 
>> I agree. If we go this route we should essentially announce an immediate
>> 5.1 alpha at the same time as 5.0 GA, and I can’t see almost anybody
>> rolling out 5.0 with 5.1 so close on its heels.
>>
>> On 23 Oct 2023, at 18:11, Aleksey Yeshchenko  wrote:
>>
>> I’m not so sure that many folks will choose to go 4.0->5.0->5.1 path
>> instead of just waiting longer for TCM+Accord to be in, and go 4.0->5.1 in
>> one hop.
>>
>> Nobody likes going through these upgrades. So I personally expect 5.0 to
>> be a largely ghost release if we go this route, adopted by few, just a
>> permanent burden on the merge path to trunk.
>>
>> Not to say that there isn’t valuable stuff in 5.0 without TCM and Accord
>> - there most certainly is - but with the expectation that 5.1 will follow
>> up reasonably shortly after with all that *and* two highly anticipated
>> features on top, I just don’t see the point. It will be another 2.2 release.
>>
>>
>> On 23 Oct 2023, at 17:43, Josh McKenzie  wrote:
>>
>> We discussed that at length in various other mailing threads Jeff - kind
>> of settled on "we're committing to cutting a major (semver MAJOR or MINOR)
>> every 12 months but want to remain flexible for exceptions when
>> appropriate".
>>
>> And then we discussed our timeline for 5.0 this year and settled on the
>> "let's try and get it out this calendar year so it's 12 months after 4.1,
>> but we'll grandfather in TCM and Accord past freeze date if they can make
>> it by October".
>>
>> So that's the history for how we landed here.
>>
>> 2) Do we drop the support of 3.0 and 3.11 after 5.0.0 is out or after
>> 5.1.0 is?
>>
>> This is my understanding, yes. Deprecation and support drop is predicated
>> on the 5.0 release, not any specific features or anything.
>>
>> On Mon, Oct 23, 2023, at 12:29 PM, Jeff Jirsa wrote:
>>
>>
>>
>> On Mon, Oct 23, 2023 at 4:52 AM Mick Semb Wever  wrote:
>>
>>
>> The TCM work (CEP-21) is in its review stage but being well past our
>> cut-off date¹ for merging, and now jeopardising 5.0 GA efforts, I would
>> like to propose the following.
>>
>>
>>
>> I think this presumes that 5.0 GA is date driven instead of feature
>> driven.
>>
>> I'm sure there's a conversation elsewhere, but why isn't this date
>> movable?
>>
>>
>>

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Josh McKenzie]

> If I had to pick a month of the year to release software used by large 
> enterprises, it probably would be something like March instead of December.
That's... a good point. If we end up on a cadence of major's in December (since 
we slipped to then for 4.1 and inherit that from that calendar year "pressure") 
we're setting ourselves up to release right in the largest consistent 
change-freeze window I know of for most users.

> It will be another 2.2 release.
Let me live on with the stories I tell myself about the hordes of Windows users 
that appreciated Windows support before the Storage Engine rewrite, thank you 
very much. :D

On Mon, Oct 23, 2023, at 1:57 PM, Caleb Rackliffe wrote:
> ...or like the end of January. Either way, feel free to ignore the "aside" :)
> 
> On Mon, Oct 23, 2023 at 12:53 PM Caleb Rackliffe  
> wrote:
>> Kind of in the same place as Benedict/Aleksey.
>> 
>> If we release a 5.1 in, let's say...March of next year, the number of 5.0 
>> users is going to be very minimal. Nobody is going to upgrade anything 
>> important from now through the first half of January anyway, right? They're 
>> going to be making sure their existing clusters aren't exploding.
>> 
>> (We still want TCM/Accord to be available to people to test by Summit, but 
>> that feels unrelated to whether we cut a 5.1 branch...)
>> 
>> Aside: If I had to pick a month of the year to release software used by 
>> large enterprises, it probably would be something like March instead of 
>> December. I have no good research to back that up, of course... 
>> 
>> On Mon, Oct 23, 2023 at 12:19 PM Benedict  wrote:
>>> 
>>> To be clear, I’m not making an argument either way about the path forwards 
>>> we should take, just concurring about a likely downside of this proposal. I 
>>> don’t have a strong opinion about how we should proceed.
>>> 
>>> 
 On 23 Oct 2023, at 18:16, Benedict  wrote:
 
 
 I agree. If we go this route we should essentially announce an immediate 
 5.1 alpha at the same time as 5.0 GA, and I can’t see almost anybody 
 rolling out 5.0 with 5.1 so close on its heels.
 
 
> On 23 Oct 2023, at 18:11, Aleksey Yeshchenko  wrote:
> I’m not so sure that many folks will choose to go 4.0->5.0->5.1 path 
> instead of just waiting longer for TCM+Accord to be in, and go 4.0->5.1 
> in one hop.
> 
> Nobody likes going through these upgrades. So I personally expect 5.0 to 
> be a largely ghost release if we go this route, adopted by few, just a 
> permanent burden on the merge path to trunk.
> 
> Not to say that there isn’t valuable stuff in 5.0 without TCM and Accord 
> - there most certainly is - but with the expectation that 5.1 will follow 
> up reasonably shortly after with all that *and* two highly anticipated 
> features on top, I just don’t see the point. It will be another 2.2 
> release.
> 
> 
>> On 23 Oct 2023, at 17:43, Josh McKenzie  wrote:
>> 
>> We discussed that at length in various other mailing threads Jeff - kind 
>> of settled on "we're committing to cutting a major (semver MAJOR or 
>> MINOR) every 12 months but want to remain flexible for exceptions when 
>> appropriate".
>> 
>> And then we discussed our timeline for 5.0 this year and settled on the 
>> "let's try and get it out this calendar year so it's 12 months after 
>> 4.1, but we'll grandfather in TCM and Accord past freeze date if they 
>> can make it by October".
>> 
>> So that's the history for how we landed here.
>> 
>>> 2) Do we drop the support of 3.0 and 3.11 after 5.0.0 is out or after 
>>> 5.1.0 is?
>> This is my understanding, yes. Deprecation and support drop is 
>> predicated on the 5.0 release, not any specific features or anything.
>> 
>> On Mon, Oct 23, 2023, at 12:29 PM, Jeff Jirsa wrote:
>>> 
>>> 
>>> On Mon, Oct 23, 2023 at 4:52 AM Mick Semb Wever  wrote:
 
 The TCM work (CEP-21) is in its review stage but being well past our 
 cut-off date¹ for merging, and now jeopardising 5.0 GA efforts, I 
 would like to propose the following.
 
>>> 
>>> 
>>> I think this presumes that 5.0 GA is date driven instead of feature 
>>> driven.
>>> 
>>> I'm sure there's a conversation elsewhere, but why isn't this date 
>>> movable?

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Jeff Jirsa]

Why ship a ghost release we dont really expect people to use. Why not just
move the date so all the PR content highlighting TCM+Accord isnt a mess?

I get it, nobody wants to move dates. Isn't that the least-bad option?

On Mon, Oct 23, 2023 at 11:28 AM Aleksey Yeshchenko 
wrote:

> I’m not so sure that many folks will choose to go 4.0->5.0->5.1 path
> instead of just waiting longer for TCM+Accord to be in, and go 4.0->5.1 in
> one hop.
>
> Nobody likes going through these upgrades. So I personally expect 5.0 to
> be a largely ghost release if we go this route, adopted by few, just a
> permanent burden on the merge path to trunk.
>
> Not to say that there isn’t valuable stuff in 5.0 without TCM and Accord -
> there most certainly is - but with the expectation that 5.1 will follow up
> reasonably shortly after with all that *and* two highly anticipated
> features on top, I just don’t see the point. It will be another 2.2 release.
>
>
> On 23 Oct 2023, at 17:43, Josh McKenzie  wrote:
>
> We discussed that at length in various other mailing threads Jeff - kind
> of settled on "we're committing to cutting a major (semver MAJOR or MINOR)
> every 12 months but want to remain flexible for exceptions when
> appropriate".
>
> And then we discussed our timeline for 5.0 this year and settled on the
> "let's try and get it out this calendar year so it's 12 months after 4.1,
> but we'll grandfather in TCM and Accord past freeze date if they can make
> it by October".
>
> So that's the history for how we landed here.
>
> 2) Do we drop the support of 3.0 and 3.11 after 5.0.0 is out or after
> 5.1.0 is?
>
> This is my understanding, yes. Deprecation and support drop is predicated
> on the 5.0 release, not any specific features or anything.
>
> On Mon, Oct 23, 2023, at 12:29 PM, Jeff Jirsa wrote:
>
>
>
> On Mon, Oct 23, 2023 at 4:52 AM Mick Semb Wever  wrote:
>
>
> The TCM work (CEP-21) is in its review stage but being well past our
> cut-off date¹ for merging, and now jeopardising 5.0 GA efforts, I would
> like to propose the following.
>
>
>
> I think this presumes that 5.0 GA is date driven instead of feature driven.
>
> I'm sure there's a conversation elsewhere, but why isn't this date movable?
>
>
>

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Aaron Ploetz]

>
> If I had to pick a month of the year to release software used by large
> enterprises, it probably would be something like March instead of December.
> I have no good research to back that up, of course...
>

Can confirm. Many large enterprises (especially retailers) have been in
"holiday code freeze" for a few weeks already. Infrastructure teams will be
freezing all changes shortly (they get a few "buffer" weeks to scale-out
for holiday traffic). Everything is basically locked-down until the week
after New Years.

Once infra teams can push changes again, they'll likely have a backlog of
findings from their security team, indicating a list of things that need to
be patched/updated across all of their server instances. At Target, we
usually had to spend all of January playing "catch-up" to make the security
scans happy again.

Maybe by mid-February, they'll be ready to entertain doing a database
update. So the February/March timeframe is a good choice.

Aaron


On Mon, Oct 23, 2023 at 1:12 PM Josh McKenzie  wrote:

> If I had to pick a month of the year to release software used by large
> enterprises, it probably would be something like March instead of December.
>
> That's... a good point. If we end up on a cadence of major's in December
> (since we slipped to then for 4.1 and inherit that from that calendar year
> "pressure") we're setting ourselves up to release right in the largest
> consistent change-freeze window I know of for most users.
>
> It will be another 2.2 release.
>
> Let me live on with the stories I tell myself about the hordes of Windows
> users that appreciated Windows support before the Storage Engine rewrite,
> thank you very much. :D
>
> On Mon, Oct 23, 2023, at 1:57 PM, Caleb Rackliffe wrote:
>
> ...or like the end of January. Either way, feel free to ignore the "aside"
> :)
>
> On Mon, Oct 23, 2023 at 12:53 PM Caleb Rackliffe 
> wrote:
>
> Kind of in the same place as Benedict/Aleksey.
>
> If we release a 5.1 in, let's say...March of next year, the number of 5.0
> users is going to be very minimal. Nobody is going to upgrade anything
> important from now through the first half of January anyway, right? They're
> going to be making sure their existing clusters aren't exploding.
>
> (We still want TCM/Accord to be available to people to test by Summit, but
> that feels unrelated to whether we cut a 5.1 branch...)
>
> Aside: If I had to pick a month of the year to release software used by
> large enterprises, it probably would be something like March instead of
> December. I have no good research to back that up, of course...
>
> On Mon, Oct 23, 2023 at 12:19 PM Benedict  wrote:
>
>
> To be clear, I’m not making an argument either way about the path forwards
> we should take, just concurring about a likely downside of this proposal. I
> don’t have a strong opinion about how we should proceed.
>
>
> On 23 Oct 2023, at 18:16, Benedict  wrote:
>
> 
>
> I agree. If we go this route we should essentially announce an immediate
> 5.1 alpha at the same time as 5.0 GA, and I can’t see almost anybody
> rolling out 5.0 with 5.1 so close on its heels.
>
>
> On 23 Oct 2023, at 18:11, Aleksey Yeshchenko  wrote:
>
> I’m not so sure that many folks will choose to go 4.0->5.0->5.1 path
> instead of just waiting longer for TCM+Accord to be in, and go 4.0->5.1 in
> one hop.
>
> Nobody likes going through these upgrades. So I personally expect 5.0 to
> be a largely ghost release if we go this route, adopted by few, just a
> permanent burden on the merge path to trunk.
>
> Not to say that there isn’t valuable stuff in 5.0 without TCM and Accord -
> there most certainly is - but with the expectation that 5.1 will follow up
> reasonably shortly after with all that *and* two highly anticipated
> features on top, I just don’t see the point. It will be another 2.2 release.
>
>
> On 23 Oct 2023, at 17:43, Josh McKenzie  wrote:
>
> We discussed that at length in various other mailing threads Jeff - kind
> of settled on "we're committing to cutting a major (semver MAJOR or MINOR)
> every 12 months but want to remain flexible for exceptions when
> appropriate".
>
> And then we discussed our timeline for 5.0 this year and settled on the
> "let's try and get it out this calendar year so it's 12 months after 4.1,
> but we'll grandfather in TCM and Accord past freeze date if they can make
> it by October".
>
> So that's the history for how we landed here.
>
> 2) Do we drop the support of 3.0 and 3.11 after 5.0.0 is out or after
> 5.1.0 is?
>
> This is my understanding, yes. Deprecation and support drop is predicated
> on the 5.0 release, not any specific features or anything.
>
> On Mon, Oct 23, 2023, at 12:29 PM, Jeff Jirsa wrote:
>
>
>
> On Mon, Oct 23, 2023 at 4:52 AM Mick Semb Wever  wrote:
>
>
> The TCM work (CEP-21) is in its review stage but being well past our
> cut-off date¹ for merging, and now jeopardising 5.0 GA efforts, I would
> like to propose the following.
>
>
>
> I think this presumes that 5.0 GA

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Eric Evans]

On Mon, Oct 23, 2023 at 1:36 PM Jeff Jirsa  wrote:

> Why ship a ghost release we dont really expect people to use. Why not just
> move the date so all the PR content highlighting TCM+Accord isnt a mess?
>

We won't move to 5.x until some time after the dust settles, and I can't
see us starting that timer until after 5.1 (assuming that's when TCM+Accord
lands).


>
> I get it, nobody wants to move dates. Isn't that the least-bad option?
>

I think so.


>
> On Mon, Oct 23, 2023 at 11:28 AM Aleksey Yeshchenko 
> wrote:
>
>> I’m not so sure that many folks will choose to go 4.0->5.0->5.1 path
>> instead of just waiting longer for TCM+Accord to be in, and go 4.0->5.1 in
>> one hop.
>>
>> Nobody likes going through these upgrades. So I personally expect 5.0 to
>> be a largely ghost release if we go this route, adopted by few, just a
>> permanent burden on the merge path to trunk.
>>
>> Not to say that there isn’t valuable stuff in 5.0 without TCM and Accord
>> - there most certainly is - but with the expectation that 5.1 will follow
>> up reasonably shortly after with all that *and* two highly anticipated
>> features on top, I just don’t see the point. It will be another 2.2 release.
>>
>>
>> On 23 Oct 2023, at 17:43, Josh McKenzie  wrote:
>>
>> We discussed that at length in various other mailing threads Jeff - kind
>> of settled on "we're committing to cutting a major (semver MAJOR or MINOR)
>> every 12 months but want to remain flexible for exceptions when
>> appropriate".
>>
>> And then we discussed our timeline for 5.0 this year and settled on the
>> "let's try and get it out this calendar year so it's 12 months after 4.1,
>> but we'll grandfather in TCM and Accord past freeze date if they can make
>> it by October".
>>
>> So that's the history for how we landed here.
>>
>> 2) Do we drop the support of 3.0 and 3.11 after 5.0.0 is out or after
>> 5.1.0 is?
>>
>> This is my understanding, yes. Deprecation and support drop is predicated
>> on the 5.0 release, not any specific features or anything.
>>
>> On Mon, Oct 23, 2023, at 12:29 PM, Jeff Jirsa wrote:
>>
>>
>>
>> On Mon, Oct 23, 2023 at 4:52 AM Mick Semb Wever  wrote:
>>
>>
>> The TCM work (CEP-21) is in its review stage but being well past our
>> cut-off date¹ for merging, and now jeopardising 5.0 GA efforts, I would
>> like to propose the following.
>>
>>
>>
>> I think this presumes that 5.0 GA is date driven instead of feature
>> driven.
>>
>> I'm sure there's a conversation elsewhere, but why isn't this date
>> movable?
>>
>>
>>

-- 
Eric Evans 
Staff SRE, Data Persistence
Wikimedia Foundation

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Jon Haddad]

>From the folks I've been talking to - Accord is one of the biggest things to 
>be excited about in 5.0.  Everyone giving a presentation about the 5.0 release 
>has been hyping up accord.  

Shipping a release to make a date (that means practically nothing to most 
people) by gutting one of the most useful features is a bad tradeoff.

Jon

On 2023/10/23 14:39:36 Patrick McFadin wrote:
> I'm really surprised to see this email. The last I heard everything was on
> track for getting into 5.0 and TBH and Accord is what a majority of users
> are expecting in 5.0. And how could this be a .1 release?
> 
> What is it going to take to get it into 5.0? What is off track and how did
> we get here?
> 
> On Mon, Oct 23, 2023 at 6:51 AM Sam Tunnicliffe  wrote:
> 
> > +1 from me too.
> >
> > Regarding Benedict's point, backwards incompatibility should be minimal;
> > we modified snitch behaviour slightly, so that local snitch config only
> > relates to the local node, all peer info is fetched from cluster metadata.
> > There is also a minor change to the way failed bootstraps are handled, as
> > with TCM they require an explicit cancellation step (running a nodetool
> > command).
> >
> > Whether consensus decrees that this constitutes a major bump or not, I
> > think decoupling these major projects from 5.0 is the right move.
> >
> >
> > On 23 Oct 2023, at 12:57, Benedict  wrote:
> >
> > I’m cool with this.
> >
> > We may have to think about numbering as I think TCM will break some
> > backwards compatibility and we might technically expect the follow-up
> > release to be 6.0
> >
> > Maybe it’s not so bad to have such rapid releases either way.
> >
> > On 23 Oct 2023, at 12:52, Mick Semb Wever  wrote:
> >
> > 
> >
> > The TCM work (CEP-21) is in its review stage but being well past our
> > cut-off date¹ for merging, and now jeopardising 5.0 GA efforts, I would
> > like to propose the following.
> >
> > We merge TCM and Accord only to trunk.  Then branch cassandra-5.1 and cut
> > an immediate 5.1-alpha1 release.
> >
> > I see this as a win-win scenario for us, considering our current
> > situation.  (Though it is unfortunate that Accord is included in this
> > scenario because we agreed it to be based upon TCM.)
> >
> > This will mean…
> >  - We get to focus on getting 5.0 to beta and GA, which already has a ton
> > of features users want.
> >  - We get an alpha release with TCM and Accord into users hands quickly
> > for broader testing and feedback.
> >  - We isolate GA efforts on TCM and Accord – giving oss and downstream
> > engineers time and patience reviewing and testing.  TCM will be the biggest
> > patch ever to land in C*.
> >  - Give users a choice for a more incremental upgrade approach, given just
> > how many new features we're putting on them in one year.
> >  - 5.1 w/ TCM and Accord will maintain its upgrade compatibility with all
> > 4.x versions, just as if it had landed in 5.0.
> >
> >
> > The risks/costs this introduces are
> >  - If we cannot stabilise TCM and/or Accord on the cassandra-5.1 branch,
> > and at some point decide to undo this work, while we can throw away the
> > cassandra-5.1 branch we would need to do a bit of work reverting the
> > changes in trunk.  This is a _very_ edge case, as confidence levels on the
> > design and implementation of both are already tested and high.
> >  - We will have to maintain an additional branch.  I propose that we treat
> > the 5.1 branch in the same maintenance window as 5.0 (like we have with 3.0
> > and 3.11).  This also adds the merge path overhead.
> >  - Reviewing of TCM and Accord will continue to happen post-merge.  This
> > is not our normal practice, but this work will have already received its
> > two +1s from committers, and such ongoing review effort is akin to GA
> > stabilisation work on release branches.
> >
> >
> > I see no other ok solution in front of us that gets us at least both the
> > 5.0 beta and TCM+Accord alpha releases this year.  Keeping in mind users
> > demand to start experimenting with these features, and our Cassandra Summit
> > in December.
> >
> >
> > 1) https://lists.apache.org/thread/9c5cnn57c7oqw8wzo3zs0dkrm4f17lm3
> >
> >
> >
> >
> 

Re: [DISCUSS] CEP-36: A Configurable ChannelProxy to alias external storage locations

[Jon Haddad]

I think this is a great more generally useful than the two scenarios you've 
outlined.  I think it could / should be possible to use an object store as the 
primary storage for sstables and rely on local disk as a cache for reads.  

I don't know the roadmap for TCM, but imo if it allowed for more stable, 
pre-allocated ranges that compaction will always be aware of (plus a bunch of 
plumbing I'm deliberately avoiding the details on), then you could bootstrap a 
new node by copying s3 directories around rather than streaming data between 
nodes.  That's how we get to 20TB / node, easy scale up / down, etc, and 
always-ZCS for non-object store deployments.

Jon

On 2023/09/25 06:48:06 "Claude Warren, Jr via dev" wrote:
> I have just filed CEP-36 [1] to allow for keyspace/table storage outside of
> the standard storage space.
> 
> There are two desires  driving this change:
> 
>1. The ability to temporarily move some keyspaces/tables to storage
>outside the normal directory tree to other disk so that compaction can
>occur in situations where there is not enough disk space for compaction and
>the processing to the moved data can not be suspended.
>2. The ability to store infrequently used data on slower cheaper storage
>layers.
> 
> I have a working POC implementation [2] though there are some issues still
> to be solved and much logging to be reduced.
> 
> I look forward to productive discussions,
> Claude
> 
> [1]
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-36%3A+A+Configurable+ChannelProxy+to+alias+external+storage+locations
> [2] https://github.com/Claudenw/cassandra/tree/channel_proxy_factory
> 

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Dinesh Joshi]

I have a strong preference to move out the 5.0 date to have accord and TCM. I 
don’t see the point in shipping 5.0 without these features especially if 5.1 is 
going to follow close behind it.

Dinesh

> On Oct 23, 2023, at 4:52 AM, Mick Semb Wever  wrote:
> 
> 
> 
> The TCM work (CEP-21) is in its review stage but being well past our cut-off 
> date¹ for merging, and now jeopardising 5.0 GA efforts, I would like to 
> propose the following.
> 
> We merge TCM and Accord only to trunk.  Then branch cassandra-5.1 and cut an 
> immediate 5.1-alpha1 release.
> 
> I see this as a win-win scenario for us, considering our current situation.  
> (Though it is unfortunate that Accord is included in this scenario because we 
> agreed it to be based upon TCM.)
> 
> This will mean…
>  - We get to focus on getting 5.0 to beta and GA, which already has a ton of 
> features users want.
>  - We get an alpha release with TCM and Accord into users hands quickly for 
> broader testing and feedback.
>  - We isolate GA efforts on TCM and Accord – giving oss and downstream 
> engineers time and patience reviewing and testing.  TCM will be the biggest 
> patch ever to land in C*.
>  - Give users a choice for a more incremental upgrade approach, given just 
> how many new features we're putting on them in one year.
>  - 5.1 w/ TCM and Accord will maintain its upgrade compatibility with all 4.x 
> versions, just as if it had landed in 5.0.
> 
> 
> The risks/costs this introduces are
>  - If we cannot stabilise TCM and/or Accord on the cassandra-5.1 branch, and 
> at some point decide to undo this work, while we can throw away the 
> cassandra-5.1 branch we would need to do a bit of work reverting the changes 
> in trunk.  This is a _very_ edge case, as confidence levels on the design and 
> implementation of both are already tested and high.
>  - We will have to maintain an additional branch.  I propose that we treat 
> the 5.1 branch in the same maintenance window as 5.0 (like we have with 3.0 
> and 3.11).  This also adds the merge path overhead.
>  - Reviewing of TCM and Accord will continue to happen post-merge.  This is 
> not our normal practice, but this work will have already received its two +1s 
> from committers, and such ongoing review effort is akin to GA stabilisation 
> work on release branches.
> 
> 
> I see no other ok solution in front of us that gets us at least both the 5.0 
> beta and TCM+Accord alpha releases this year.  Keeping in mind users demand 
> to start experimenting with these features, and our Cassandra Summit in 
> December.
> 
> 
> 1) https://lists.apache.org/thread/9c5cnn57c7oqw8wzo3zs0dkrm4f17lm3
> 
> 

CASSANDRA-18941 produce size bounded SSTables from CQLSSTableWriter

[Yifan Cai]

Hi,

I want to propose merging the patch in CASSANDRA-18941 to 4.0 and up to
trunk and hope we are all OK with it.

In CASSANDRA-18941, I am adding the capability to produce size-bounded
SSTables in CQLSSTableWriter for sorted data. It can greatly benefit
Cassandra Analytics (https://github.com/apache/cassandra-analytics) for
bulk writing SSTables, since it avoids buffering and sorting on flush,
given the data source is sorted already in the bulk write process.
Cassandra Analytics supports Cassandra 4.0 and depends on the cassandra-all
4.0.x library. Therefore, we are mostly interested in using the new
capability in 4.0.

CQLSSTableWriter is only used in offline tools and never in the code path
of Cassandra server.

Any objections to merging the patch to 4.0 and up to trunk?

- Yifan

Re: CASSANDRA-18941 produce size bounded SSTables from CQLSSTableWriter

[Francisco Guerrero]

+1 (nb). I think this is a great addition to offline tools that use SSTable 
writer in general.

On 2023/10/23 23:21:13 Yifan Cai wrote:
> Hi,
> 
> I want to propose merging the patch in CASSANDRA-18941 to 4.0 and up to
> trunk and hope we are all OK with it.
> 
> In CASSANDRA-18941, I am adding the capability to produce size-bounded
> SSTables in CQLSSTableWriter for sorted data. It can greatly benefit
> Cassandra Analytics (https://github.com/apache/cassandra-analytics) for
> bulk writing SSTables, since it avoids buffering and sorting on flush,
> given the data source is sorted already in the bulk write process.
> Cassandra Analytics supports Cassandra 4.0 and depends on the cassandra-all
> 4.0.x library. Therefore, we are mostly interested in using the new
> capability in 4.0.
> 
> CQLSSTableWriter is only used in offline tools and never in the code path
> of Cassandra server.
> 
> Any objections to merging the patch to 4.0 and up to trunk?
> 
> - Yifan
> 

Re: CASSANDRA-18941 produce size bounded SSTables from CQLSSTableWriter

[guo Maxwell]

+1, but I want to know why only trunk and 4.0 ? not all the versions
involved, like 4.1 ,5.0 。

Francisco Guerrero  于2023年10月24日周二 07:47写道：

> +1 (nb). I think this is a great addition to offline tools that use
> SSTable writer in general.
>
> On 2023/10/23 23:21:13 Yifan Cai wrote:
> > Hi,
> >
> > I want to propose merging the patch in CASSANDRA-18941 to 4.0 and up to
> > trunk and hope we are all OK with it.
> >
> > In CASSANDRA-18941, I am adding the capability to produce size-bounded
> > SSTables in CQLSSTableWriter for sorted data. It can greatly benefit
> > Cassandra Analytics (https://github.com/apache/cassandra-analytics) for
> > bulk writing SSTables, since it avoids buffering and sorting on flush,
> > given the data source is sorted already in the bulk write process.
> > Cassandra Analytics supports Cassandra 4.0 and depends on the
> cassandra-all
> > 4.0.x library. Therefore, we are mostly interested in using the new
> > capability in 4.0.
> >
> > CQLSSTableWriter is only used in offline tools and never in the code path
> > of Cassandra server.
> >
> > Any objections to merging the patch to 4.0 and up to trunk?
> >
> > - Yifan
> >
>