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

[C. Scott Andreas]

I’d love to see this implemented — where “this” is a proxy for some notion of support for remote object storage, perhaps usable by compaction strategies like TWCS to migrate data older than a threshold from a local filesystem to remote object.It’s not an area where I can currently dedicate engineering effort. But if others are interested in contributing a feature like this, I’d see it as valuable for the project and would be happy to collaborate on design/architecture/goals.– ScottOn Feb 26, 2025, at 6:56 AM, guo Maxwell  wrote:Is anyone else interested in continuing to discuss this topic?guo Maxwell  于2024年9月20日周五 09:44写道：I discussed this offline with Claude, he is no longer working on this. It's a pity. I think this is a very valuable thing. Commitlog's archiving and restore may be able to use the relevant code if it is completed.Patrick McFadin 于2024年9月20日 周五上午2:01写道：Thanks for reviving this one!On Wed, Sep 18, 2024 at 12:06 AM guo Maxwell  wrote:Is there any update on this topic?  It seems that things can make a big progress if  Jake Luciani  can find someone who can make the FileSystemProvider code accessible. Jon Haddad  于2023年12月16日周六 05:29写道：At a high level I really like the idea of being able to better leverage cheaper storage especially object stores like S3.  One important thing though - I feel pretty strongly that there's a big, deal breaking downside.   Backups, disk failure policies, snapshots and possibly repairs would get more complicated which haven't been particularly great in the past, and of course there's the issue of failure recovery being only partially possible if you're looking at a durable block store paired with an ephemeral one with some of your data not replicated to the cold side.  That introduces a failure case that's unacceptable for most teams, which results in needing to implement potentially 2 different backup solutions.  This is operationally complex with a lot of surface area for headaches.  I think a lot of teams would probably have an issue with the big question mark around durability and I probably would avoid it myself.On the other hand, I'm +1 if we approach it something slightly differently - where _all_ the data is located on the cold storage, with the local hot storage used as a cache.  This means we can use the cold directories for the complete dataset, simplifying backups and node replacements.  For a little background, we had a ticket several years ago where I pointed out it was possible to do this *today* at the operating system level as long as you're using block devices (vs an object store) and LVM [1].  For example, this works well with GP3 EBS w/ low IOPS provisioning + local NVMe to get a nice balance of great read performance without going nuts on the cost for IOPS.  I also wrote about this in a little more detail in my blog [2].  There's also the new mount point tech in AWS which pretty much does exactly what I've suggested above [3] that's probably worth evaluating just to get a feel for it.  I'm not insisting we require LVM or the AWS S3 fs, since that would rule out other cloud providers, but I am pretty confident that the entire dataset should reside in the "cold" side of things for the practical and technical reasons I listed above.  I don't think it massively changes the proposal, and should simplify things for everyone.Jon[1] https://rustyrazorblade.com/post/2018/2018-04-24-intro-to-lvm/[2] https://issues.apache.org/jira/browse/CASSANDRA-8460[3] https://aws.amazon.com/about-aws/whats-new/2023/03/mountpoint-amazon-s3/On Thu, Dec 14, 2023 at 1:56 AM Claude Warren  wrote:Is there still interest in this?  Can we get some points down on electrons so that we all understand the issues?

While it is fairly simple to redirect the read/write to something other  than the local system for a single node this will not solve the problem for tiered storage.

Tiered storage will require that on read/write the primary key be assessed and determine if the read/write should be redirected.  My reasoning for this statement is that in a cluster with a replication factor greater than 1 the node will store data for the keys that would be allocated to it in a cluster with a replication factor = 1, as well as some keys from nodes earlier in the ring.

Even if we can get the primary keys for all the data we want to write to "cold storage" to map to a single node a replication factor > 1 means that data will also be placed in "normal storage" on subsequent nodes.

To overcome this, we have to explore ways to route data to different storage based on the keys and that different storage may have to be available on _all_  the nodes.

Have any of the partial solutions mentioned in this email chain (or others) solved this problem?

Claude

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

[guo Maxwell]

Is anyone else interested in continuing to discuss this topic?

guo Maxwell  于2024年9月20日周五 09:44写道：

> I discussed this offline with Claude, he is no longer working on this.
>
> It's a pity. I think this is a very valuable thing. Commitlog's archiving
> and restore may be able to use the relevant code if it is completed.
>
> Patrick McFadin 于2024年9月20日 周五上午2:01写道：
>
>> Thanks for reviving this one!
>>
>> On Wed, Sep 18, 2024 at 12:06 AM guo Maxwell 
>> wrote:
>>
>>> Is there any update on this topic?  It seems that things can make a big
>>> progress if  Jake Luciani  can find someone who can make the
>>> FileSystemProvider code accessible.
>>>
>>> Jon Haddad  于2023年12月16日周六 05:29写道：
>>>
 At a high level I really like the idea of being able to better leverage
 cheaper storage especially object stores like S3.

 One important thing though - I feel pretty strongly that there's a big,
 deal breaking downside.   Backups, disk failure policies, snapshots and
 possibly repairs would get more complicated which haven't been particularly
 great in the past, and of course there's the issue of failure recovery
 being only partially possible if you're looking at a durable block store
 paired with an ephemeral one with some of your data not replicated to the
 cold side.  That introduces a failure case that's unacceptable for most
 teams, which results in needing to implement potentially 2 different backup
 solutions.  This is operationally complex with a lot of surface area for
 headaches.  I think a lot of teams would probably have an issue with the
 big question mark around durability and I probably would avoid it myself.

 On the other hand, I'm +1 if we approach it something slightly
 differently - where _all_ the data is located on the cold storage, with the
 local hot storage used as a cache.  This means we can use the cold
 directories for the complete dataset, simplifying backups and node
 replacements.

 For a little background, we had a ticket several years ago where I
 pointed out it was possible to do this *today* at the operating system
 level as long as you're using block devices (vs an object store) and LVM
 [1].  For example, this works well with GP3 EBS w/ low IOPS provisioning +
 local NVMe to get a nice balance of great read performance without going
 nuts on the cost for IOPS.  I also wrote about this in a little more detail
 in my blog [2].  There's also the new mount point tech in AWS which pretty
 much does exactly what I've suggested above [3] that's probably worth
 evaluating just to get a feel for it.

 I'm not insisting we require LVM or the AWS S3 fs, since that would
 rule out other cloud providers, but I am pretty confident that the entire
 dataset should reside in the "cold" side of things for the practical and
 technical reasons I listed above.  I don't think it massively changes the
 proposal, and should simplify things for everyone.

 Jon

 [1] https://rustyrazorblade.com/post/2018/2018-04-24-intro-to-lvm/
 [2] https://issues.apache.org/jira/browse/CASSANDRA-8460
 [3]
 https://aws.amazon.com/about-aws/whats-new/2023/03/mountpoint-amazon-s3/


 On Thu, Dec 14, 2023 at 1:56 AM Claude Warren 
 wrote:

> Is there still interest in this?  Can we get some points down on
> electrons so that we all understand the issues?
>
> While it is fairly simple to redirect the read/write to something
> other  than the local system for a single node this will not solve the
> problem for tiered storage.
>
> Tiered storage will require that on read/write the primary key be
> assessed and determine if the read/write should be redirected.  My
> reasoning for this statement is that in a cluster with a replication 
> factor
> greater than 1 the node will store data for the keys that would be
> allocated to it in a cluster with a replication factor = 1, as well as 
> some
> keys from nodes earlier in the ring.
>
> Even if we can get the primary keys for all the data we want to write
> to "cold storage" to map to a single node a replication factor > 1 means
> that data will also be placed in "normal storage" on subsequent nodes.
>
> To overcome this, we have to explore ways to route data to different
> storage based on the keys and that different storage may have to be
> available on _all_  the nodes.
>
> Have any of the partial solutions mentioned in this email chain (or
> others) solved this problem?
>
> Claude
>

Re: Welcome Jeremiah Jordan to the PMC

[Benjamin Lerer]

Congrats!

Le lun. 17 févr. 2025 à 17:50, Christopher Bradford 
a écrit :

> Well done JD!
>
> On Feb 17, 2025, at 7:08 AM, Piotr Kołaczkowski 
> wrote:
>
> Congrats Jeremiah!
>
> Wiadomość napisana przez Berenguer Blasi  w
> dniu 17.02.2025, o godz. 07:23:
>
> Congrats JD!! :-)
> On 16/2/25 20:52, Bernardo Botella wrote:
>
> Congrats!
>
> El feb 16, 2025, a las 9:08 a. m., Aaron 
>  escribió:
>
> Congratulations, JD!
>
> On Sat, Feb 15, 2025 at 7:05 AM Jasonstack Zhao Yang <
> jasonstack.z...@gmail.com> wrote:
>
>> Congrats!
>>
>> On Sat, 15 Feb 2025 at 20:25, Maxim Muzafarov  wrote:
>>
>>> Congratulation Jeremiah!
>>>
>>> On Sat, 15 Feb 2025 at 05:01, Paulo Motta  wrote:
>>> >
>>> > Congrats JD!
>>> >
>>> > On Fri, 14 Feb 2025 at 18:35 guo Maxwell  wrote:
>>> >>
>>> >> Congrats！
>>> >> Tolbert, Andy 于2025年2月15日 周六上午6:22写道：
>>> >>>
>>> >>> Congrats JD!
>>> >>>
>>> >>> On Fri, Feb 14, 2025 at 4:13 PM  wrote:
>>> 
>>>  Congratulations, well deserved!
>>> 
>>>  El 14 feb 2025, a las 20:40, Alex Petrov 
>>> escribió:
>>> 
>>>  
>>>  Congratulations!
>>> 
>>>  On Fri, Feb 14, 2025, at 7:33 PM, Josh McKenzie wrote:
>>> 
>>>  Congrats Jeremiah!
>>> 
>>>  I know you're excited to have yet another email list to attend to,
>>> aren't you? :D
>>> 
>>>  On Fri, Feb 14, 2025, at 1:29 PM, Jeremiah Jordan wrote:
>>> 
>>>  Thanks all!  Excited to continue being a part of the project in
>>> this new role.
>>> 
>>>  -Jeremiah Jordan
>>> 
>>>  On Feb 14, 2025 at 12:23:17 PM, Francisco Guerrero <
>>> fran...@apache.org> wrote:
>>> 
>>>  Congrats!
>>> 
>>>  On 2025/02/14 18:20:02 Yifan Cai wrote:
>>> 
>>>  Congrats!
>>> 
>>> 
>>>  On Fri, Feb 14, 2025 at 10:16 AM Jordan West 
>>> wrote:
>>> 
>>> 
>>>  > Congrats, JD! Welcome aboard!
>>> 
>>>  >
>>> 
>>>  > Jordan
>>> 
>>>  >
>>> 
>>>  > On Fri, Feb 14, 2025 at 11:01 Mick Semb Wever 
>>> wrote:
>>> 
>>>  >
>>> 
>>>  >>.
>>> 
>>>  >>
>>> 
>>>  >> > I hope you will join me in welcoming him to the committee.
>>> 
>>>  >>
>>> 
>>>  >>
>>> 
>>>  >> Welcome JD!
>>> 
>>>  >>
>>> 
>>>  >
>>> 
>>> 
>>> 
>>> 
>>>
>>
>
>
>

Re: Welcome Caleb Rackliffe to the PMC

[Benjamin Lerer]

Congratulations!

Le sam. 22 févr. 2025 à 13:41, Dmitry Konstantinov  a
écrit :

> Congratulations Caleb!
>
> On Fri, 21 Feb 2025 at 23:21, Yifan Cai  wrote:
>
>> Congrats Caleb!
>> --
>> *From:* Štefan Miklošovič 
>> *Sent:* Friday, February 21, 2025 11:44:42 AM
>> *To:* dev@cassandra.apache.org 
>> *Subject:* Re: Welcome Caleb Rackliffe to the PMC
>>
>> Congratulations Caleb, what a delivery (not only) in SAI department!
>>
>> On Thu, Feb 20, 2025 at 11:07 PM Jon Haddad 
>> wrote:
>>
>> The PMC for Apache Cassandra is delighted to announce that Caleb
>> Rackliffe has joined it's membership!
>>
>> Caleb has been a member of the community for 10 years and is one of the
>> most active committers on the project.
>>
>> Please join us in welcoming Caleb to his new role!
>>
>> Jon
>> On behalf of the Cassandra PMC
>>
>>
>>
>
> --
> Dmitry Konstantinov
>

Re: Welcome Caleb Rackliffe to the PMC

[Mick Semb Wever]

   .

>
> Please join us in welcoming Caleb to his new role!
>



Congratulations Caleb !!

Re: stalled PR #3585 (CASSANDRA-14098: integer overflow fix)

[Danny Faught]

I sent a request for a Jira account a month ago and I haven't gotten any
response. It seems my username was set up, but perhaps the email isn't
right. I don't receive anything when I try to do a password reset.

Can someone help me with the account?

-Danny

On Tue, Jan 21, 2025 at 1:41 PM Dinesh Joshi  wrote:

> Hi Danny,
>
> Thanks for pinging this ist. It would be helpful for you to indicate on
> that JIRA that you're picking up the issue. Right now the JIRA is not
> assigned to anybody. I don't think you have a JIRA account. Could you
> please request[1] one? Once you have it, I will assign you the ticket and
> you can post your update in the ticket with the git branch with your fix.
> Please respond back to the list and hopefully someone will review your
> ticket and merge it in.
>
> It would be great for you to review the general guidelines[2] for
> contributing to the project.
>
> thanks,
>
> Dinesh
>
>
> [1] https://selfserve.apache.org/jira-account.html
> [2] https://cassandra.apache.org/_/development/patches.html
>
> On Mon, Jan 20, 2025 at 1:50 PM Danny Faught 
> wrote:
>
>> Hi! New contributor to the project here. I opened PR 3585
>> (CASSANDRA-14098: integer overflow fix)
>>  last September to
>> address a Jira ticket that has been open for quite some time (
>> https://issues.apache.org/jira/browse/CASSANDRA-14098).
>>
>> I can imagine it's a low priority for the project, and if it's simply
>> waiting for someone to have the time to review it, no worries. But if I
>> missed something in the process that I should have done, please let me
>> know.
>>
>> I'm considering using this PR as a code sample for a conference
>> presentation, and if there is feedback on whether any changes are needed,
>> that would give me the opportunity to improve the code first.
>>
>> -Danny
>>
>>

Re: stalled PR #3585 (CASSANDRA-14098: integer overflow fix)

[Brandon Williams]

I don't see any requests from you, Danny.  Are you using
https://selfserve.apache.org/jira-account.html ?

Kind Regards,
Brandon

On Wed, Feb 26, 2025 at 2:50 PM Danny Faught  wrote:
>
> I sent a request for a Jira account a month ago and I haven't gotten any 
> response. It seems my username was set up, but perhaps the email isn't right. 
> I don't receive anything when I try to do a password reset.
>
> Can someone help me with the account?
>
> -Danny
>
> On Tue, Jan 21, 2025 at 1:41 PM Dinesh Joshi  wrote:
>>
>> Hi Danny,
>>
>> Thanks for pinging this ist. It would be helpful for you to indicate on that 
>> JIRA that you're picking up the issue. Right now the JIRA is not assigned to 
>> anybody. I don't think you have a JIRA account. Could you please request[1] 
>> one? Once you have it, I will assign you the ticket and you can post your 
>> update in the ticket with the git branch with your fix. Please respond back 
>> to the list and hopefully someone will review your ticket and merge it in.
>>
>> It would be great for you to review the general guidelines[2] for 
>> contributing to the project.
>>
>> thanks,
>>
>> Dinesh
>>
>>
>> [1] https://selfserve.apache.org/jira-account.html
>> [2] https://cassandra.apache.org/_/development/patches.html
>>
>> On Mon, Jan 20, 2025 at 1:50 PM Danny Faught  wrote:
>>>
>>> Hi! New contributor to the project here. I opened PR 3585 (CASSANDRA-14098: 
>>> integer overflow fix) last September to address a Jira ticket that has been 
>>> open for quite some time 
>>> (https://issues.apache.org/jira/browse/CASSANDRA-14098).
>>>
>>> I can imagine it's a low priority for the project, and if it's simply 
>>> waiting for someone to have the time to review it, no worries. But if I 
>>> missed something in the process that I should have done, please let me know.
>>>
>>> I'm considering using this PR as a code sample for a conference 
>>> presentation, and if there is feedback on whether any changes are needed, 
>>> that would give me the opportunity to improve the code first.
>>>
>>> -Danny
>>>

Re: Welcome Caleb Rackliffe to the PMC

[Jordan West]

Congrats Caleb!!

Jordan
On Wed, Feb 26, 2025 at 13:01 Mick Semb Wever  wrote:

>   .
>
>>
>> Please join us in welcoming Caleb to his new role!
>>
>
>
>
> Congratulations Caleb !!
>
>

Second commiter for CASSANDRA-20363

[Tommy Stendahl via dev]

Hi,

We need a second commit to look at CASSANDRA-20363 Add option to set a
custom FSErrorHandler,
https://issues.apache.org/jira/browse/CASSANDRA-20363

It would be much appreciated if someone could spare a moment, its a
small patch.

Regards,
/Tommy

Re: Second commiter for CASSANDRA-20363

[Brandon Williams]

I'll get it.

Kind Regards,
Brandon

On Wed, Feb 26, 2025 at 5:55 AM Tommy Stendahl via dev
 wrote:
>
> Hi,
>
> We need a second commit to look at CASSANDRA-20363 Add option to set a
> custom FSErrorHandler,
> https://issues.apache.org/jira/browse/CASSANDRA-20363
>
> It would be much appreciated if someone could spare a moment, its a
> small patch.
>
> Regards,
> /Tommy