Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

[Ariel Weisberg]

Hi,

A bit late to this discussion, there are few emails in the thread I'll respond 
to separately.

Yes it's just to implement a binary file based queue that supports realtime 
tailing. If it had been low friction it would have made more sense, but given 
the friction Chronicle's approach to OSS brings I don't think it makes much 
sense to keep using it.

It has some jankiness to it. I vaguely recall having copied the files while 
they are being written to and then gotten errors trying to read them.

I think the next time we want to add functionality to the FQL/binlog it would 
be worth re-implementing that part or even just doing it to get rid of the 
dependency.

Ariel

On Mon, Sep 16, 2024, at 5:16 PM, Benedict wrote:
> 
> Don’t we essentially just use it as a file format for storing a couple of 
> kinds of append-only data?
> 
> I was never entirely clear on the value it brought to the project.
> 
> 
>> On 16 Sep 2024, at 22:11, Jordan West  wrote:
>> 
>> Thanks for the sleuthing Stefan! This definitely is a bit unfortunate. It 
>> sounds like a replacement is not really practical so I'll ignore that option 
>> for now, until a viable alternative is proposed. I am -1 on us writing our 
>> own without strong, strong justification -- primarily because I think the 
>> likelihood is we introduce more bugs before getting to something stable. 
>> 
>> Regarding the remaining options, mostly some thoughts:
>> 
>> - it would be nice to have some specific evidence of other projects using 
>> the EA versions and what their developers have said about it.
>> - it sounds like if we go with the EA route, the onus to test for 
>> correctness / compatibility increases. They do test but anything marked 
>> "early access" I think deserves more scrutiny from the C* community before 
>> release. That could come in the form of more tests (or showing that we 
>> already have good coverage of where its used).
>> - i assume each time we upgrade we would pick the most recently released EA 
>> version
>> 
>> Jordan
>> 
>> 
>> On Mon, Sep 16, 2024 at 1:46 PM Štefan Miklošovič  
>> wrote:
>>> We are using a library called Chronicle Queue (1) and its dependencies and 
>>> we ship them in the distribution tarball.
>>> 
>>> The version we use in 5.0 / trunk as I write this is 2.23.36. If you look 
>>> closely here (2), there is one more release like this, 2.23.37 and after 
>>> that all these releases have "ea" in their name.
>>> 
>>> "ea" stands for "early access". The project has changed the versioning / 
>>> development model in such a way that "ea" releases act, more or less, as 
>>> glorified snapshots which are indeed released to Maven Central but the 
>>> "regular" releases are not there. The reason behind this is that "regular" 
>>> releases are published only for customers who pay to the company behind 
>>> this project and they offer commercial support for that.
>>> 
>>> "regular" releases are meant to get all the bug fixes after "ea" is 
>>> published and they are official stable releases. On the other hand "ea" 
>>> releases are the ones where the development happens and every now and then, 
>>> once the developers think that it is time to cut new 2.x, they just publish 
>>> that privately.
>>> 
>>> I was investigating how this all works here (3) and while they said that, I 
>>> quote (4):
>>> 
>>> "In my experience this is consumed by a large number of open source 
>>> projects reliably (for our other artifacts too). This development/ea branch 
>>> still goes through an extensive test suite prior to release. Releases from 
>>> this branch will contain the latest features and bug fixes."
>>> 
>>> I am not completely sure if we are OK with this. For the record, Mick is 
>>> not overly comfortable with that and Brandon would prefer to just replace 
>>> it / get rid of this dependency (comments / reasons / discussion from (5) 
>>> to the end)
>>> 
>>> The question is if we are OK with how things are and if we are then what 
>>> are the rules when upgrading the version of this project in Cassandra in 
>>> the context of "ea" versions they publish.
>>> 
>>> If we are not OK with this, then the question is what we are going to 
>>> replace it with.
>>> 
>>> If we are going to replace it, I very briefly took a look and there is 
>>> practically nothing out there which would hit all the buttons for us. 
>>> Chronicle is just perfect for this job and I am not a fan of rewriting this 
>>> at all. 
>>> 
>>> I would like to have this resolved because there is CEP-12 I plan to 
>>> deliver and I hit this and I do not want to base that work on something we 
>>> might eventually abandon. There are some ideas for CEP-12 how to bypass 
>>> this without using Chronicle but I would like to firstly hear your opinion.
>>> 
>>> Regards
>>> 
>>> (1) https://github.com/OpenHFT/Chronicle-Queue
>>> (2) https://repo1.maven.org/maven2/net/openhft/chronicle-core/
>>> (3) https://github.com/OpenHFT/Chronicle-Core/issues/668
>>> (4) 
>>> https://gith

Re: [VOTE] Release Apache Cassandra 4.1.7

[Brandon Williams]

+1

Kind Regards,
Brandon

On Fri, Sep 20, 2024 at 9:36 AM Mick Semb Wever  wrote:
>
>
> Proposing the test build of Cassandra 4.1.7 for release.
>
> sha1: ca494526025a480bc8530ed3ae472ce8c9cbaf7a
> Git: https://github.com/apache/cassandra/tree/4.1.7-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1347/org/apache/cassandra/cassandra-all/4.1.7/
>
> The Source and Build Artifacts, and the Debian and RPM packages and 
> repositories, are available here: 
> https://dist.apache.org/repos/dist/dev/cassandra/4.1.7/
>
> ==
> This release introduces safeguards and observability into possible data loss 
> scenarios when nodes have a  divergent view of the cluster. This happens 
> around edge-cases on unsafe bootstrapping, decommissions, or when a node has 
> a corrupted topology. Two configuration options have been added: 
> `log_out_of_token_range_requests` and  `reject_out_of_token_range_requests`, 
> both enabled by default. The former will make nodes log requests they receive 
> that don't belong in their current or pending token ranges. The latter will 
> reject those requests, which prevents any eventual data loss that can occur 
> but may also incur small windows of degraded availability during range 
> movements. See CASSANDRA-13704 for further details.
> ==
>
> The vote will be open for 96 hours (longer if needed). Everyone who has 
> tested the build is invited to vote. Votes by PMC members are considered 
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
> [1]: CHANGES.txt: 
> https://github.com/apache/cassandra/blob/4.1.7-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/4.1.7-tentative/NEWS.txt

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

[guo Maxwell]

+1 on splitting this task  and adding the ability to copy tables through
different keyspaces in the future.

Štefan Miklošovič  于2024年9月23日周一 22:05写道：

> If we have this table
>
> CREATE TABLE ks.tb2 (
> id int PRIMARY KEY,
> name text
> );
>
> I can either specify name of an index on my own like this:
>
> CREATE INDEX name_index ON ks.tb2 (name) ;
>
> or I can let Cassandra to figure that name on its own:
>
> CREATE INDEX ON ks.tb2 (name) ;
>
> in that case it will name that index "tb2_name_idx".
>
> Hence, I would expect that when we do
>
> ALTER TABLE ks.to_copy LIKE ks.tb2 WITH INDICES;
>
> Then ks.to_copy table will have an index which is called
> "to_copy_name_idx" without me doing anything.
>
> For types, we do not need to do anything when we deal with the same
> keyspace. For simplicity, I mentioned that we might deal with the same
> keyspace scenario only for now and iterate on that in the future.
>
> On Mon, Sep 23, 2024 at 8:53 AM guo Maxwell  wrote:
>
>> Hello everyone,
>>
>> Cep is being written, and I encountered some problems during the process.
>> I would like to discuss them with you. If you read the description of this
>> CASSANDRA-7662 ,
>> we will find that initially the original creator of this jira did not
>> intend to implement structural copying of indexes, views, and triggers
>> only the column and its data type.
>>
>> However, after investigating some db related syntax and function
>> implementation, I found that it may be necessary for us to provide some
>> rich syntax to support the replication of indexes, views, etc.
>>
>> In order to support selective copy of the basic structure of the table
>> (columns and types), table options, table-related indexes, views, triggers,
>> etc. We need some new syntax, it seems that the syntax of pg is relatively
>> comprehensive, it use the keyword INCLUDING/EXCLUDING to flexibly control
>> the removal and retention of indexes, table information, etc. see pg
>> create table like
>>  , the new
>> created index name is different from the original table's index name , 
>> seenewly
>> copied index names are different from original
>> 
>> , the name is based on some rule.
>> Mysql is relatively simple and copies columns and indexes by default. see 
>> mysql
>> create table like
>>  and the
>> newly created index name is the same with the original table's index name.
>>
>> So for Casandra, I hope it can also support the information copy of index
>> and even view/trigger. And I also hope to be able to flexibly decide which
>> information is copied like pg.
>>
>> Besides, I think the copy can happen between different keyspaces. And UDT
>> needs to be taken into account.
>>
>> But as we know the index/view/trigger name are all under keyspace level,
>> so it seems that the newly created index name (or view name/ trigger name)
>> must be different from the original tables' ,otherwise  names would clash .
>>
>> So regarding the above problem, one idea I have is that for newly created
>> types, indexes and views under different keyspaces and the same keyspace,
>> we first generate random names for them, and then we can add the ability of
>> modifying the names(for types/indexes/views/triggers) so that users can
>> manually change the names.
>>
>>
>> guo Maxwell  于2024年9月20日周五 08:06写道：
>>
>>> No，I think still need some discuss on grammar detail after I finish the
>>> first version
>>>
>>> Patrick McFadin 于2024年9月20日 周五上午2:24写道：
>>>
 Is this CEP ready for a VOTE thread?

 On Sat, Aug 24, 2024 at 8:56 PM guo Maxwell 
 wrote:

> Thank you for your replies, I will prepare a CEP later.
>
> Patrick McFadin  于2024年8月20日周二 02:11写道：
>
>> +1 This is a CEP
>>
>> On Mon, Aug 19, 2024 at 10:50 AM Jon Haddad 
>> wrote:
>>
>>> Given the fairly large surface area for this, i think it should be a
>>> CEP.
>>>
>>> —
>>> Jon Haddad
>>> Rustyrazorblade Consulting
>>> rustyrazorblade.com
>>>
>>>
>>> On Mon, Aug 19, 2024 at 10:44 AM Bernardo Botella <
>>> conta...@bernardobotella.com> wrote:
>>>
 Definitely a nice addition to CQL.

 Looking for inspiration at how Postgres and Mysql do that may also
 help with the final design (I like the WITH proposed by Stefan, but I 
 would
 definitely take a look at the INCLUDING keyword proposed by Postgres).
 https://www.postgresql.org/docs/current/sql-createtable.html
 https://dev.mysql.com/doc/refman/8.4/en/create-table-like.html

 On top of that, and as part of the interesting questions, I would
 like to add the permissions to the mix. Both the question about copying
 them

Re: [Discuss] CASSANDRA-17666, disable write path for cdc

[Josh McKenzie]

While it's a fairly small and simple change, 4.1 is an LTS branch right now and 
it's getting bugfixes only. If you absolutely need it for a deployment 
internally, it should be relatively easy to rejigger the patch to a checkout of 
4.1 and build a distribution of the software for yourself (see pr 
)

On Mon, Sep 23, 2024, at 6:44 AM, Nikolai Loginov wrote:
> Is it possible to  backport changes from the CASSANDRA-17666 to the 4.1 
> branch?
> 
> Regards
> 
> Nikolai Loginov

Re: [VOTE] Release Apache Cassandra 4.0.14

[Brandon Williams]

+1

Kind Regards,
Brandon

On Fri, Sep 20, 2024 at 9:36 AM Mick Semb Wever  wrote:
>
>
> Proposing the test build of Cassandra 4.0.14 for release.
>
> sha1: 7bf67349579411521bcdee4febd209cff63179a6
> Git: https://github.com/apache/cassandra/tree/4.0.14-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1345/org/apache/cassandra/cassandra-all/4.0.14/
>
> The Source and Build Artifacts, and the Debian and RPM packages and 
> repositories, are available here: 
> https://dist.apache.org/repos/dist/dev/cassandra/4.0.14/
>
> ==
> This release introduces safeguards and observability into possible data loss 
> scenarios when nodes have a  divergent view of the cluster. This happens 
> around edge-cases on unsafe bootstrapping, decommissions, or when a node has 
> a corrupted topology. Two configuration options have been added: 
> `log_out_of_token_range_requests` and  `reject_out_of_token_range_requests`, 
> both enabled by default. The former will make nodes log requests they receive 
> that don't belong in their current or pending token ranges. The latter will 
> reject those requests, which prevents any eventual data loss that can occur 
> but may also incur small windows of degraded availability during range 
> movements. See CASSANDRA-13704 for further details.
> ==
>
> The vote will be open for 96 hours (longer if needed). Everyone who has 
> tested the build is invited to vote. Votes by PMC members are considered 
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
> [1]: CHANGES.txt: 
> https://github.com/apache/cassandra/blob/4.0.14-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/4.0.14-tentative/NEWS.txt

Re: [VOTE] Release Apache Cassandra 5.0.1

[Maxim Muzafarov]

+1

On Fri, 20 Sept 2024 at 16:36, Mick Semb Wever  wrote:
>
>
> Proposing the test build of Cassandra 5.0.1 for release.
>
> sha1: c206e4509003ac4cd99147d821bd4b5d23bdf5e8
> Git: https://github.com/apache/cassandra/tree/5.0.1-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1348/org/apache/cassandra/cassandra-all/5.0.1/
>
> The Source and Build Artifacts, and the Debian and RPM packages and 
> repositories, are available here: 
> https://dist.apache.org/repos/dist/dev/cassandra/5.0.1/
>
> ==
> This release introduces safeguards and observability into possible data loss 
> scenarios when nodes have a  divergent view of the cluster. This happens 
> around edge-cases on unsafe bootstrapping, decommissions, or when a node has 
> a corrupted topology. Two configuration options have been added: 
> `log_out_of_token_range_requests` and  `reject_out_of_token_range_requests`, 
> both enabled by default. The former will make nodes log requests they receive 
> that don't belong in their current or pending token ranges. The latter will 
> reject those requests, which prevents any eventual data loss that can occur 
> but may also incur small windows of degraded availability during range 
> movements. See CASSANDRA-13704 for further details.
> ==
>
> The vote will be open for 96 hours (longer if needed). Everyone who has 
> tested the build is invited to vote. Votes by PMC members are considered 
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
> [1]: CHANGES.txt: 
> https://github.com/apache/cassandra/blob/5.0.1-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/5.0.1-tentative/NEWS.txt

Re: [VOTE] Release Apache Cassandra 4.1.7

[Maxim Muzafarov]

+1

On Mon, 23 Sept 2024 at 01:59, Jordan West  wrote:
>
> +1. Validated by starting and creating a 3 node cluster using easy-cass-lab.
>
> Jordan
>
> On Fri, Sep 20, 2024 at 7:36 AM Mick Semb Wever  wrote:
>>
>>
>> Proposing the test build of Cassandra 4.1.7 for release.
>>
>> sha1: ca494526025a480bc8530ed3ae472ce8c9cbaf7a
>> Git: https://github.com/apache/cassandra/tree/4.1.7-tentative
>> Maven Artifacts: 
>> https://repository.apache.org/content/repositories/orgapachecassandra-1347/org/apache/cassandra/cassandra-all/4.1.7/
>>
>> The Source and Build Artifacts, and the Debian and RPM packages and 
>> repositories, are available here: 
>> https://dist.apache.org/repos/dist/dev/cassandra/4.1.7/
>>
>> ==
>> This release introduces safeguards and observability into possible data loss 
>> scenarios when nodes have a  divergent view of the cluster. This happens 
>> around edge-cases on unsafe bootstrapping, decommissions, or when a node has 
>> a corrupted topology. Two configuration options have been added: 
>> `log_out_of_token_range_requests` and  `reject_out_of_token_range_requests`, 
>> both enabled by default. The former will make nodes log requests they 
>> receive that don't belong in their current or pending token ranges. The 
>> latter will reject those requests, which prevents any eventual data loss 
>> that can occur but may also incur small windows of degraded availability 
>> during range movements. See CASSANDRA-13704 for further details.
>> ==
>>
>> The vote will be open for 96 hours (longer if needed). Everyone who has 
>> tested the build is invited to vote. Votes by PMC members are considered 
>> binding. A vote passes if there are at least three binding +1s and no -1's.
>>
>> [1]: CHANGES.txt: 
>> https://github.com/apache/cassandra/blob/4.1.7-tentative/CHANGES.txt
>> [2]: NEWS.txt: 
>> https://github.com/apache/cassandra/blob/4.1.7-tentative/NEWS.txt

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

[Ariel Weisberg]

Hi,

> I just don't understand what "good enough performance" is. 
Should really specify throughput. There is a single thread writing records to 
the log and it's a bottleneck around a few hundred thousand entries/sec and 
1gb/sec. It doesn't scale to arbitrary throughput requirements.

> What is a "predictable footprint"? Was that measured too? How did we quantify 
> that?
You can set a rolling cycle to limit the size of the log. It's not that 
predictable disk space wise because rolling is time based, and that is one of 
the things I don't like about Chronicle.

> This is interesting, if I understand correctly, the messages are weighted and 
> the heavier they are, the more probable it is they will be dropped when it is 
> overloaded? Or vice versa, the tighter ones are dropped first?
It's still a FIFO queue. Elements aren't dropped from the queue they are 
dropped by the producers who don't have to wait for the consumer of the queue 
to catch up. The queue size is described in terms of weight not number of 
elements so it can bound memory usage.

> Have we _ever_ experienced in production that some log events were really 
> dropped? Has anybody ever hit that?
Dropping samples is off by default so it can be used in a lossless way.

Notionally one of the use cases of full query logging is that you have a 
cluster that is overloaded and want to find out what is causing it. These nodes 
maybe low on IO/CPU and turning on the full query log could cause additional 
timeouts so one goal of the full query log is that enabling it shouldn't make 
things worse.

That is the motivation for memory limits and not blocking request threads on 
IO. Really there should also be rate limits and random sampling because right 
now dropping samples will be biased towards dropping large footprint samples.

David Capwell mentioned some performance issues. I recall we talked about it 
and I did a quick microbenchmark and didn't have a problem writing records (1 
gigabyte/sec, hundreds of thousands of entries) so I am not sure what scenarios 
is where performance is bad and whether it is addressable. Not sure it matters 
since Chronicle's approach to OSS is so problematic. 

Ariel

On Tue, Sep 17, 2024, at 4:27 AM, Štefan Miklošovič wrote:
> to Benedict:
> 
> well ... I was not around when the decision about the usage of Chronicle 
> Queues was made. I think that at that time it was the most obvious candidate 
> without reinventing the wheel given the features and capabilities it had so 
> taking something off the shelf was a natural conclusion.
> 
> Josh / Jordan:
> 
> not only FQL but Audit as well these are two separate things. There is also 
> quite a "rich" ecosystem around that.
> 
> 1) nodetool commands like
> 
> enableauditlog
> enablefullquerylog
> disableauditlog
> disablefullquerylog
> getauditlog
> getfullquerylog
> 
> Also, because the files it produces are binary, we need a special tooling to 
> inspect it, it is in tools/fqltool with a bunch of classes, and there is also 
> an AuditLogViewer for reviewing audit logs.
> 
> There are MBean methods enabling nodetool commands.
> 
> We have also shipped that in two major releases (4.0 and now in 5.0) so the 
> community is quite well used to this, they have the processes set around this 
> etc.
> 
> I mention this all because it is just not so easy to replace it with 
> something else if somebody wanted that, in any case. How do we even go around 
> deprecating this if we are indeed going to replace that?
> 
> To discuss the release aspect they have in place: I think you are right that 
> the latest ea is as close as possible, if not the same, as what they release 
> privately. Yes. But if we want to stick to the rule that we upgrade only to 
> the latest ea relese before their next minor, then 
> 
> 1) we will be always at least one minor late
> 2) we do not know when they make up their minds to transition to a new minor 
> so we can upgrade to the latest ea one minor before 
> 3) if something is broken and we need to fix it and we are on ea, then what 
> we get to update to is the latest ea at that time which might fix the issue 
> but it will also bring new stuff in which might open doors to instability as 
> well. So we update to fix the bugs but we might include new ones unknowingly.
> 
> Anyway, I don't think this has any silver bullet solution, we might just 
> stick to the latest "ea" and be done with it. I do not expect this project to 
> evolve wildly and unpredictably, it just solves "one problem", there is 
> basically nothing new coming in.
> 
> Brandon:
> 
> I understand your concerns about phoning home but 
> 
> 1) we already resolved this by setting the respective property
> 2) I do not think that Chronicle will mess with this once they introduce 
> that. There is nothing to "improve" or "change" there. It is phoning home or 
> not and it is driven by one property. If they made a change that we can not 
> turn it off then we would really be in trouble bu

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

[guo Maxwell]

If there are multiple schema information changes in one ddl statement, will
there be schema conflicts in extreme cases?
For example, our statement contains both table creation and index creation.

guo Maxwell 于2024年9月24日 周二下午8:12写道：

> +1 on splitting this task  and adding the ability to copy tables through
> different keyspaces in the future.
>
> Štefan Miklošovič  于2024年9月23日周一 22:05写道：
>
>> If we have this table
>>
>> CREATE TABLE ks.tb2 (
>> id int PRIMARY KEY,
>> name text
>> );
>>
>> I can either specify name of an index on my own like this:
>>
>> CREATE INDEX name_index ON ks.tb2 (name) ;
>>
>> or I can let Cassandra to figure that name on its own:
>>
>> CREATE INDEX ON ks.tb2 (name) ;
>>
>> in that case it will name that index "tb2_name_idx".
>>
>> Hence, I would expect that when we do
>>
>> ALTER TABLE ks.to_copy LIKE ks.tb2 WITH INDICES;
>>
>> Then ks.to_copy table will have an index which is called
>> "to_copy_name_idx" without me doing anything.
>>
>> For types, we do not need to do anything when we deal with the same
>> keyspace. For simplicity, I mentioned that we might deal with the same
>> keyspace scenario only for now and iterate on that in the future.
>>
>> On Mon, Sep 23, 2024 at 8:53 AM guo Maxwell  wrote:
>>
>>> Hello everyone,
>>>
>>> Cep is being written, and I encountered some problems during the
>>> process. I would like to discuss them with you. If you read the description
>>> of this CASSANDRA-7662
>>> , we will find
>>> that initially the original creator of this jira did not intend to
>>> implement structural copying of indexes, views, and triggers  only the
>>> column and its data type.
>>>
>>> However, after investigating some db related syntax and function
>>> implementation, I found that it may be necessary for us to provide some
>>> rich syntax to support the replication of indexes, views, etc.
>>>
>>> In order to support selective copy of the basic structure of the table
>>> (columns and types), table options, table-related indexes, views, triggers,
>>> etc. We need some new syntax, it seems that the syntax of pg is relatively
>>> comprehensive, it use the keyword INCLUDING/EXCLUDING to flexibly control
>>> the removal and retention of indexes, table information, etc. see pg
>>> create table like
>>>  , the new
>>> created index name is different from the original table's index name , 
>>> seenewly
>>> copied index names are different from original
>>> 
>>> , the name is based on some rule.
>>> Mysql is relatively simple and copies columns and indexes by default.
>>> see mysql create table like
>>>  and
>>> the newly created index name is the same with the original table's index
>>> name.
>>>
>>> So for Casandra, I hope it can also support the information copy of
>>> index and even view/trigger. And I also hope to be able to flexibly decide
>>> which information is copied like pg.
>>>
>>> Besides, I think the copy can happen between different keyspaces. And
>>> UDT needs to be taken into account.
>>>
>>> But as we know the index/view/trigger name are all under keyspace level,
>>> so it seems that the newly created index name (or view name/ trigger name)
>>> must be different from the original tables' ,otherwise  names would clash .
>>>
>>> So regarding the above problem, one idea I have is that for newly
>>> created types, indexes and views under different keyspaces and the same
>>> keyspace, we first generate random names for them, and then we can add the
>>> ability of modifying the names(for types/indexes/views/triggers) so that
>>> users can manually change the names.
>>>
>>>
>>> guo Maxwell  于2024年9月20日周五 08:06写道：
>>>
 No，I think still need some discuss on grammar detail after I finish the
 first version

 Patrick McFadin 于2024年9月20日 周五上午2:24写道：

> Is this CEP ready for a VOTE thread?
>
> On Sat, Aug 24, 2024 at 8:56 PM guo Maxwell 
> wrote:
>
>> Thank you for your replies, I will prepare a CEP later.
>>
>> Patrick McFadin  于2024年8月20日周二 02:11写道：
>>
>>> +1 This is a CEP
>>>
>>> On Mon, Aug 19, 2024 at 10:50 AM Jon Haddad 
>>> wrote:
>>>
 Given the fairly large surface area for this, i think it should be
 a CEP.

 —
 Jon Haddad
 Rustyrazorblade Consulting
 rustyrazorblade.com


 On Mon, Aug 19, 2024 at 10:44 AM Bernardo Botella <
 conta...@bernardobotella.com> wrote:

> Definitely a nice addition to CQL.
>
> Looking for inspiration at how Postgres and Mysql do that may also
> help with the final design (I like the WITH proposed by Stefan, but I 
> would
> definitely take a look at t

Re: 【DISCUSS】The configuration of Commitlog archiving

[guo Maxwell]

Hello，are there any new updates？🤔

guo Maxwell 于2024年9月18日 周三下午4:06写道：

> Do you have any new updates  on this DISCUSS ?
>
> - The reason this pattern is popular is it allows extension of
> functionality ahead of the database. Some people copy to a NAS/SAN. Some
> people copy to S3. Some people copy to their own object storage that isn’t
> s3 compatible. “Compress and move” is super limiting, because “move” varies
> remarkably between environments.
>
> Yes, it is indeed very flexible to use this way, but would it be more
> appropriate to decouple the file archiving to heterogeneous storage and
> leave it to other systems to handle it specifically? And we only do
> compression and copying (file linking like sstable incremental backup)?
>
>
> Štefan Miklošovič  于2024年9月5日周四 04:18写道：
>
>>
>> On Wed, Sep 4, 2024 at 8:34 PM Jon Haddad  wrote:
>>
>>> I thought about this a bit over the last few days, and there's actually
>>> quite a few problems present that would need to be addressed.
>>>
>>> *Insecure JMX*
>>>
>>> First off - if someone has access to JMX, the entire system is already
>>> compromised.  A bad actor can mess with the cluster topology, truncate
>>> tables, and do a ton of other disruptive stuff.  But if we're going to go
>>> down this path I think we should apply your logic consistently to avoid
>>> creating a "solution" that has the same "problem" as we do now.  I use
>>> quotes because I'm not entirely convinced the root cause of the problem is
>>> enabling some shell access, but I'll entertain it for the sake of the
>>> discussion.
>>>
>>> *Dynamic Configuration and Shell Scripts*
>>>
>>> Let's pretend that somehow an open JMX isn't already a *massive*
>>> security flaw by itself.  Once an attacker has control of a system, the
>>> next phase of the attack relies on them dynamically changing the
>>> configuration to point to a different shell script, or to execute arbitrary
>>> shell scripts.
>>>
>> I agree with the general idea that we don't want this - so in my mind the
>>> necessary solution here is to disable the ability to change the commit log
>>> archiving behavior at runtime.
>>>
>>> The idea that commit log archiving (and many other config settings)
>>> would be dynamically configurable is a massive security flaw that should be
>>> disallowed.  If you want to take this a step further and claim there's a
>>> flaw with shell scripts in general, I'll even entertain that for a minute,
>>> but we need to examine if the proposed solution of moving code to Java
>>> actually solves the problem.
>>>
>>> *Dynamic Configuration and Java Code*
>>>
>>> Let's say we've removed the ability to use shell scripts, and we've
>>> gotten people to rewrite their shell code with java code, but we've left
>>> the dynamic configuration in.  Going back to my original email, I mentioned
>>> copying commit logs off the node and into an object store.  If someone is
>>> able to change the parameter dynamically at runtime, they could just as
>>> easily point to a public S3 bucket and commit logs would be archived there
>>> which is just as bad as the shell version.  So if we are to convert this
>>> functionality to Java, we should also be making best practice
>>> recommendations on what users should and should not do.
>>>
>>
>> I think what you meant here is that if we allowed people to provide a
>> pluggable way how stuff is copied over and they would code it up, put that
>> JAR on the class path, Cassandra (re)started etc, then someone might
>> reconfigure this custom solution in runtime? Yeah, we do not want this. We
>> can make it pluggable, but not reconfigurable. To have it pluggable and not
>> reconfigurable, then to replace it with something else, an attacker would
>> basically need to restart Cassandra with a rogue JAR on the class path. In
>> order to do that, I think that at this point it would be beyond any
>> salvation and the system is completely compromised anyway.
>>
>>
>>>
>>>
>>> *Apply All Operational Best Practices*
>>>
>>> There's been a variety of examples of how a user can further compromise
>>> a machine once they have JMX, working in tandem with shell scripts, but I
>>> hope at this point you can see that the issue is fundamentally more complex
>>> than simply disallowing shell scripts.  The issue is present in the Java
>>> examples as well, and is strongly tied to the issue of dynamic config.  If
>>> we're to design this the "right" way, I think we'd want these properties:
>>>
>>> * Commit log archiving should only have the ability to compress and move
>>> files to a staging location
>>> * Once the files are moved to the staging location, the file should be
>>> moved somewhere else by a script NOT run as the C* user.
>>>
>> * The commit log archive configuration should not be dynamically
>>> updatable, nor should any config affecting directories
>>>
>>
>> This would essentially copy the logic we have for snapshots as Jordan
>> mentioned. I do not mind having it like that. It is a good questi

Re: [VOTE] Release Apache Cassandra 4.1.7

[Štefan Miklošovič]

+1

On Fri, Sep 20, 2024 at 4:36 PM Mick Semb Wever  wrote:

>
> Proposing the test build of Cassandra 4.1.7 for release.
>
> sha1: ca494526025a480bc8530ed3ae472ce8c9cbaf7a
> Git: https://github.com/apache/cassandra/tree/4.1.7-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1347/org/apache/cassandra/cassandra-all/4.1.7/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.1.7/
>
> ==
> This release introduces safeguards and observability into possible data
> loss scenarios when nodes have a  divergent view of the cluster. This
> happens around edge-cases on unsafe bootstrapping, decommissions, or when a
> node has a corrupted topology. Two configuration options have been added:
> `log_out_of_token_range_requests` and
>  `reject_out_of_token_range_requests`, both enabled by default. The former
> will make nodes log requests they receive that don't belong in their
> current or pending token ranges. The latter will reject those requests,
> which prevents any eventual data loss that can occur but may also incur
> small windows of degraded availability during range movements. See
> CASSANDRA-13704 for further details.
> ==
>
> The vote will be open for 96 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
> [1]: CHANGES.txt:
> https://github.com/apache/cassandra/blob/4.1.7-tentative/CHANGES.txt
> [2]: NEWS.txt:
> https://github.com/apache/cassandra/blob/4.1.7-tentative/NEWS.txt
>

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

[Štefan Miklošovič]

I am sorry I do not follow what you mean, maybe an example would help.

On Tue, Sep 24, 2024 at 6:18 PM guo Maxwell  wrote:

>
> If there are multiple schema information changes in one ddl statement,
> will there be schema conflicts in extreme cases?
> For example, our statement contains both table creation and index creation.
>
> guo Maxwell 于2024年9月24日 周二下午8:12写道：
>
>> +1 on splitting this task  and adding the ability to copy tables through
>> different keyspaces in the future.
>>
>> Štefan Miklošovič  于2024年9月23日周一 22:05写道：
>>
>>> If we have this table
>>>
>>> CREATE TABLE ks.tb2 (
>>> id int PRIMARY KEY,
>>> name text
>>> );
>>>
>>> I can either specify name of an index on my own like this:
>>>
>>> CREATE INDEX name_index ON ks.tb2 (name) ;
>>>
>>> or I can let Cassandra to figure that name on its own:
>>>
>>> CREATE INDEX ON ks.tb2 (name) ;
>>>
>>> in that case it will name that index "tb2_name_idx".
>>>
>>> Hence, I would expect that when we do
>>>
>>> ALTER TABLE ks.to_copy LIKE ks.tb2 WITH INDICES;
>>>
>>> Then ks.to_copy table will have an index which is called
>>> "to_copy_name_idx" without me doing anything.
>>>
>>> For types, we do not need to do anything when we deal with the same
>>> keyspace. For simplicity, I mentioned that we might deal with the same
>>> keyspace scenario only for now and iterate on that in the future.
>>>
>>> On Mon, Sep 23, 2024 at 8:53 AM guo Maxwell 
>>> wrote:
>>>
 Hello everyone,

 Cep is being written, and I encountered some problems during the
 process. I would like to discuss them with you. If you read the description
 of this CASSANDRA-7662
 , we will find
 that initially the original creator of this jira did not intend to
 implement structural copying of indexes, views, and triggers  only the
 column and its data type.

 However, after investigating some db related syntax and function
 implementation, I found that it may be necessary for us to provide some
 rich syntax to support the replication of indexes, views, etc.

 In order to support selective copy of the basic structure of the table
 (columns and types), table options, table-related indexes, views, triggers,
 etc. We need some new syntax, it seems that the syntax of pg is relatively
 comprehensive, it use the keyword INCLUDING/EXCLUDING to flexibly control
 the removal and retention of indexes, table information, etc. see pg
 create table like
  , the new
 created index name is different from the original table's index name , 
 seenewly
 copied index names are different from original
 
 , the name is based on some rule.
 Mysql is relatively simple and copies columns and indexes by default.
 see mysql create table like
  and
 the newly created index name is the same with the original table's index
 name.

 So for Casandra, I hope it can also support the information copy of
 index and even view/trigger. And I also hope to be able to flexibly decide
 which information is copied like pg.

 Besides, I think the copy can happen between different keyspaces. And
 UDT needs to be taken into account.

 But as we know the index/view/trigger name are all under keyspace
 level, so it seems that the newly created index name (or view name/ trigger
 name) must be different from the original tables' ,otherwise  names would
 clash .

 So regarding the above problem, one idea I have is that for newly
 created types, indexes and views under different keyspaces and the same
 keyspace, we first generate random names for them, and then we can add the
 ability of modifying the names(for types/indexes/views/triggers) so that
 users can manually change the names.


 guo Maxwell  于2024年9月20日周五 08:06写道：

> No，I think still need some discuss on grammar detail after I finish
> the first version
>
> Patrick McFadin 于2024年9月20日 周五上午2:24写道：
>
>> Is this CEP ready for a VOTE thread?
>>
>> On Sat, Aug 24, 2024 at 8:56 PM guo Maxwell 
>> wrote:
>>
>>> Thank you for your replies, I will prepare a CEP later.
>>>
>>> Patrick McFadin  于2024年8月20日周二 02:11写道：
>>>
 +1 This is a CEP

 On Mon, Aug 19, 2024 at 10:50 AM Jon Haddad 
 wrote:

> Given the fairly large surface area for this, i think it should be
> a CEP.
>
> —
> Jon Haddad
> Rustyrazorblade Consulting
> rustyrazorblade.com
>
>
> On Mon, Aug 19, 2024 at 10:44 AM Bernardo Botella <
> conta...@bernardobotella.com> wrote:
>
>>

Re: [VOTE] Release Apache Cassandra 4.0.14

[Štefan Miklošovič]

+1

On Fri, Sep 20, 2024 at 4:36 PM Mick Semb Wever  wrote:

>
> Proposing the test build of Cassandra 4.0.14 for release.
>
> sha1: 7bf67349579411521bcdee4febd209cff63179a6
> Git: https://github.com/apache/cassandra/tree/4.0.14-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1345/org/apache/cassandra/cassandra-all/4.0.14/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.0.14/
>
> ==
> This release introduces safeguards and observability into possible data
> loss scenarios when nodes have a  divergent view of the cluster. This
> happens around edge-cases on unsafe bootstrapping, decommissions, or when a
> node has a corrupted topology. Two configuration options have been added:
> `log_out_of_token_range_requests` and
>  `reject_out_of_token_range_requests`, both enabled by default. The former
> will make nodes log requests they receive that don't belong in their
> current or pending token ranges. The latter will reject those requests,
> which prevents any eventual data loss that can occur but may also incur
> small windows of degraded availability during range movements. See
> CASSANDRA-13704 for further details.
> ==
>
> The vote will be open for 96 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
> [1]: CHANGES.txt:
> https://github.com/apache/cassandra/blob/4.0.14-tentative/CHANGES.txt
> [2]: NEWS.txt:
> https://github.com/apache/cassandra/blob/4.0.14-tentative/NEWS.txt
>

Re: 【DISCUSS】The configuration of Commitlog archiving

[Jon Haddad]

I categorize this as Not a Problem.

So far the two main justifications have been operator error and a fairly
convoluted series of steps to an already compromised database.  I don't
view either of them as a reason to inconvenience users.

If someone wants to avoid the shell command, what's wrong with CDC?

Jon




On Tue, Sep 24, 2024 at 9:21 AM guo Maxwell  wrote:

> Hello，are there any new updates？🤔
>
> guo Maxwell 于2024年9月18日 周三下午4:06写道：
>
>> Do you have any new updates  on this DISCUSS ?
>>
>> - The reason this pattern is popular is it allows extension of
>> functionality ahead of the database. Some people copy to a NAS/SAN. Some
>> people copy to S3. Some people copy to their own object storage that isn’t
>> s3 compatible. “Compress and move” is super limiting, because “move” varies
>> remarkably between environments.
>>
>> Yes, it is indeed very flexible to use this way, but would it be more
>> appropriate to decouple the file archiving to heterogeneous storage and
>> leave it to other systems to handle it specifically? And we only do
>> compression and copying (file linking like sstable incremental backup)?
>>
>>
>> Štefan Miklošovič  于2024年9月5日周四 04:18写道：
>>
>>>
>>> On Wed, Sep 4, 2024 at 8:34 PM Jon Haddad  wrote:
>>>
 I thought about this a bit over the last few days, and there's actually
 quite a few problems present that would need to be addressed.

 *Insecure JMX*

 First off - if someone has access to JMX, the entire system is already
 compromised.  A bad actor can mess with the cluster topology, truncate
 tables, and do a ton of other disruptive stuff.  But if we're going to go
 down this path I think we should apply your logic consistently to avoid
 creating a "solution" that has the same "problem" as we do now.  I use
 quotes because I'm not entirely convinced the root cause of the problem is
 enabling some shell access, but I'll entertain it for the sake of the
 discussion.

 *Dynamic Configuration and Shell Scripts*

 Let's pretend that somehow an open JMX isn't already a *massive*
 security flaw by itself.  Once an attacker has control of a system, the
 next phase of the attack relies on them dynamically changing the
 configuration to point to a different shell script, or to execute arbitrary
 shell scripts.

>>> I agree with the general idea that we don't want this - so in my mind
 the necessary solution here is to disable the ability to change the commit
 log archiving behavior at runtime.

 The idea that commit log archiving (and many other config settings)
 would be dynamically configurable is a massive security flaw that should be
 disallowed.  If you want to take this a step further and claim there's a
 flaw with shell scripts in general, I'll even entertain that for a minute,
 but we need to examine if the proposed solution of moving code to Java
 actually solves the problem.

 *Dynamic Configuration and Java Code*

 Let's say we've removed the ability to use shell scripts, and we've
 gotten people to rewrite their shell code with java code, but we've left
 the dynamic configuration in.  Going back to my original email, I mentioned
 copying commit logs off the node and into an object store.  If someone is
 able to change the parameter dynamically at runtime, they could just as
 easily point to a public S3 bucket and commit logs would be archived there
 which is just as bad as the shell version.  So if we are to convert this
 functionality to Java, we should also be making best practice
 recommendations on what users should and should not do.

>>>
>>> I think what you meant here is that if we allowed people to provide a
>>> pluggable way how stuff is copied over and they would code it up, put that
>>> JAR on the class path, Cassandra (re)started etc, then someone might
>>> reconfigure this custom solution in runtime? Yeah, we do not want this. We
>>> can make it pluggable, but not reconfigurable. To have it pluggable and not
>>> reconfigurable, then to replace it with something else, an attacker would
>>> basically need to restart Cassandra with a rogue JAR on the class path. In
>>> order to do that, I think that at this point it would be beyond any
>>> salvation and the system is completely compromised anyway.
>>>
>>>


 *Apply All Operational Best Practices*

 There's been a variety of examples of how a user can further compromise
 a machine once they have JMX, working in tandem with shell scripts, but I
 hope at this point you can see that the issue is fundamentally more complex
 than simply disallowing shell scripts.  The issue is present in the Java
 examples as well, and is strongly tied to the issue of dynamic config.  If
 we're to design this the "right" way, I think we'd want these properties:

 * Commit log archiving should only have the ability to co