Re: Java distributed upgrade tests fail and issue with CircleCI generate.sh script

[Ekaterina Dimitrova]

Upgrade tests fixed, please rebase your branches on latest trunk


On Tue, 25 Jul 2023 at 13:03, Ekaterina Dimitrova 
wrote:

> 1 of 2 is resolved.
> The CircleCI script is fixed, you might want to rebase trunk.
>
> On Tue, 25 Jul 2023 at 12:05, Ekaterina Dimitrova 
> wrote:
>
>> Hi all,
>> All java distributed upgrade tests fail at the moment.
>> Testing a potential fix in CASSANDRA-18690.
>> Apologize for the issue.
>> After this issue is fixed you should not be seeing any other failures
>> than the SSLFactoryTest as pointed last night.
>>
>> Also, I added a small fix for generate.sh script which was silently
>> ignoring the -e option and not detecting new/modified tests. It is also
>> under testing in CASSANDRA-18255. Anyone is welcome to test it
>>
>> Apologies for the inconvenience caused. Both should be resolved today.
>>
>> Best regards,
>> Ekaterina
>>
>

Re: Status Update on CEP-7 Storage Attached Indexes (SAI)

[Caleb Rackliffe]

Just a quick update...

With CASSANDRA-18670
 complete,
and all remaining items in the category of performance optimizations and
further testing, the process of merging to trunk will likely start today,
beginning with a final rebase on the current trunk and J11 and J17 test
runs.

On Tue, Jul 18, 2023 at 3:47 PM Caleb Rackliffe 
wrote:

> Hello there!
>
> After much toil, the first phase of CEP-7 is nearing completion (see
> CASSANDRA-16052 ).
> There are presently two issues to resolve before we'd like to merge the
> cep-7-sai feature branch and all its goodness to trunk:
>
> CASSANDRA-18670  -
> Importer should build SSTable indexes successfully before making new
> SSTables readable (in review)
>
> CASSANDRA-18673  -
> Reduce size of per-SSTable index components (in progress)
>
> (We've been getting clean CircleCI runs for a while now, and have been
> using the multiplexer to sniff out as much flakiness as possible up front.)
>
> Once merged to trunk, the next steps are:
>
> 1.) Finish a Harry model that we can use to further fuzz test SAI before
> 5.0 releases (see CASSANDRA-18275
> ). We've done a
> fair amount of fuzz/randomized testing at the component level, but I'd
> still consider Harry (at least around single-partition query use-cases) a
> critical item for us to have confidence before release.
>
> 2.) Start pursuing Phase 2 items as time and our needs allow. (see
> CASSANDRA-18473 )
>
> A reminder, SAI is a secondary index, and therefore is by definition an
> opt-in feature, and has no explicit "feature flag". However, its
> availability to users is still subject to the secondary_indexes_enabled
> guardrail, which currently defaults to allowing creation.
>
> Any thoughts, questions, or comments on the pre-merge plan here?
>

Re: [Discuss] Repair inside C*

[Jeremiah Jordan]

 +1 for the side car being the right location.

-Jeremiah

On Jul 25, 2023 at 1:16:14 PM, Chris Lohfink  wrote:

> I think a CEP is the next step. Considering the number of companies
> involved, this might necessitate several drafts and rounds of discussions.
> I appreciate your initiative in starting this process, and I'm eager to
> contribute to the ensuing discussions. Maybe in a google docs or something
> initially for more interactive feedback?
>
> In regards to https://issues.apache.org/jira/browse/CASSANDRA-14346 we at
> Netflix are actually putting effort currently to move this into the sidecar
> as the idea was to start moving non-read/write path things into different
> process and jvms to not impact each other.
>
> I think the sidecar/in process discussion might be a bit contentious as I
> know even things like compaction some feel should be moved out of process
> in future. On a personal note, my primary interest lies in seeing the
> implementation realized, so I am willing to support whatever consensus
> emerges. Whichever direction these go we will help with the implementation.
>
> Chris
>
> On Tue, Jul 25, 2023 at 1:09 PM Jaydeep Chovatia <
> chovatia.jayd...@gmail.com> wrote:
>
>> Sounds good, German. Feel free to let me know if you need my help
>> in filing CEP, adding supporting content to the CEP, etc.
>> As I mentioned previously, I have already been working (going through an
>> internal review) on creating a one-pager doc, code, etc., that has been
>> working for us for the last six years at an immense scale, and I will share
>> it soon on a private fork.
>>
>> Thanks,
>> Jaydeep
>>
>> On Tue, Jul 25, 2023 at 9:48 AM German Eichberger via dev <
>> dev@cassandra.apache.org> wrote:
>>
>>> In [2] we suggested that the next step should be a CEP.
>>>
>>> I am happy to lend a hand to this effort as well.
>>>
>>> Thanks Jaydeep and David - really appreciated.
>>>
>>> German
>>>
>>> --
>>> *From:* David Capwell 
>>> *Sent:* Tuesday, July 25, 2023 8:32 AM
>>> *To:* dev 
>>> *Cc:* German Eichberger 
>>> *Subject:* [EXTERNAL] Re: [Discuss] Repair inside C*
>>>
>>> As someone who has done a lot of work trying to make repair stable, I
>>> approve of this message ^_^
>>>
>>> More than glad to help mentor this work
>>>
>>> On Jul 24, 2023, at 6:29 PM, Jaydeep Chovatia <
>>> chovatia.jayd...@gmail.com> wrote:
>>>
>>> To clarify the repair solution timing, the one we have listed in the
>>> article is not the recently developed one. We were hitting some
>>> high-priority production challenges back in early 2018, and to address
>>> that, we developed and rolled out the solution in production in just a few
>>> months. The timing-wise, the solution was developed and productized by Q3
>>> 2018, of course, continued to evolve thereafter. Usually, we explore the
>>> existing solutions we can leverage, but when we started our journey in
>>> early 2018, most of the solutions were based on sidecar solutions. There is
>>> nothing against the sidecar solution; it was just a pure business decision,
>>> and in that, we wanted to avoid the sidecar to avoid a dependency on the
>>> control plane. Every solution developed has its deep context, merits, and
>>> pros and cons; they are all great solutions!
>>>
>>> An appeal to the community members is to think one more time about
>>> having repairs in the Open Source Cassandra itself. As mentioned in my
>>> previous email, any solution getting adopted is fine; the important aspect
>>> is to have a repair solution in the OSS Cassandra itself!
>>>
>>> Yours Faithfully,
>>> Jaydeep
>>>
>>> On Mon, Jul 24, 2023 at 3:46 PM Jaydeep Chovatia <
>>> chovatia.jayd...@gmail.com> wrote:
>>>
>>> Hi German,
>>>
>>> The goal is always to backport our learnings back to the community. For
>>> example, I have already successfully backported the following two
>>> enhancements/bug fixes back to the Open Source Cassandra, which are
>>> described in the article. I am already currently working on open-source a
>>> few more enhancements mentioned in the article back to the open-source.
>>>
>>>1. https://issues.apache.org/jira/browse/CASSANDRA-18555
>>>2. https://issues.apache.org/jira/browse/CASSANDRA-13740
>>>
>>> There is definitely heavy interest in having the repair solution inside
>>> the Open Source Cassandra itself, very much like Compaction. As I write
>>> this email, we are internally working on a one-pager proposal doc to all
>>> the community members on having a repair inside the OSS Apache Cassandra
>>> along with our private fork - I will share it soon.
>>>
>>> Generally, we are ok with any solution getting adopted (either Joey's
>>> solution or our repair solution or any other solution). The primary
>>> motivation is to have the repair embedded inside the open-source Cassandra
>>> itself, so we can retire all various privately developed solutions
>>> eventually :)
>>>
>>> I am also happy to help (drive conversation, discussion, etc.) in any
>>> 

Re: [Discuss] Repair inside C*

[Chris Lohfink]

I think a CEP is the next step. Considering the number of companies
involved, this might necessitate several drafts and rounds of discussions.
I appreciate your initiative in starting this process, and I'm eager to
contribute to the ensuing discussions. Maybe in a google docs or something
initially for more interactive feedback?

In regards to https://issues.apache.org/jira/browse/CASSANDRA-14346 we at
Netflix are actually putting effort currently to move this into the sidecar
as the idea was to start moving non-read/write path things into different
process and jvms to not impact each other.

I think the sidecar/in process discussion might be a bit contentious as I
know even things like compaction some feel should be moved out of process
in future. On a personal note, my primary interest lies in seeing the
implementation realized, so I am willing to support whatever consensus
emerges. Whichever direction these go we will help with the implementation.

Chris

On Tue, Jul 25, 2023 at 1:09 PM Jaydeep Chovatia 
wrote:

> Sounds good, German. Feel free to let me know if you need my help
> in filing CEP, adding supporting content to the CEP, etc.
> As I mentioned previously, I have already been working (going through an
> internal review) on creating a one-pager doc, code, etc., that has been
> working for us for the last six years at an immense scale, and I will share
> it soon on a private fork.
>
> Thanks,
> Jaydeep
>
> On Tue, Jul 25, 2023 at 9:48 AM German Eichberger via dev <
> dev@cassandra.apache.org> wrote:
>
>> In [2] we suggested that the next step should be a CEP.
>>
>> I am happy to lend a hand to this effort as well.
>>
>> Thanks Jaydeep and David - really appreciated.
>>
>> German
>>
>> --
>> *From:* David Capwell 
>> *Sent:* Tuesday, July 25, 2023 8:32 AM
>> *To:* dev 
>> *Cc:* German Eichberger 
>> *Subject:* [EXTERNAL] Re: [Discuss] Repair inside C*
>>
>> As someone who has done a lot of work trying to make repair stable, I
>> approve of this message ^_^
>>
>> More than glad to help mentor this work
>>
>> On Jul 24, 2023, at 6:29 PM, Jaydeep Chovatia 
>> wrote:
>>
>> To clarify the repair solution timing, the one we have listed in the
>> article is not the recently developed one. We were hitting some
>> high-priority production challenges back in early 2018, and to address
>> that, we developed and rolled out the solution in production in just a few
>> months. The timing-wise, the solution was developed and productized by Q3
>> 2018, of course, continued to evolve thereafter. Usually, we explore the
>> existing solutions we can leverage, but when we started our journey in
>> early 2018, most of the solutions were based on sidecar solutions. There is
>> nothing against the sidecar solution; it was just a pure business decision,
>> and in that, we wanted to avoid the sidecar to avoid a dependency on the
>> control plane. Every solution developed has its deep context, merits, and
>> pros and cons; they are all great solutions!
>>
>> An appeal to the community members is to think one more time about having
>> repairs in the Open Source Cassandra itself. As mentioned in my previous
>> email, any solution getting adopted is fine; the important aspect is to
>> have a repair solution in the OSS Cassandra itself!
>>
>> Yours Faithfully,
>> Jaydeep
>>
>> On Mon, Jul 24, 2023 at 3:46 PM Jaydeep Chovatia <
>> chovatia.jayd...@gmail.com> wrote:
>>
>> Hi German,
>>
>> The goal is always to backport our learnings back to the community. For
>> example, I have already successfully backported the following two
>> enhancements/bug fixes back to the Open Source Cassandra, which are
>> described in the article. I am already currently working on open-source a
>> few more enhancements mentioned in the article back to the open-source.
>>
>>1. https://issues.apache.org/jira/browse/CASSANDRA-18555
>>2. https://issues.apache.org/jira/browse/CASSANDRA-13740
>>
>> There is definitely heavy interest in having the repair solution inside
>> the Open Source Cassandra itself, very much like Compaction. As I write
>> this email, we are internally working on a one-pager proposal doc to all
>> the community members on having a repair inside the OSS Apache Cassandra
>> along with our private fork - I will share it soon.
>>
>> Generally, we are ok with any solution getting adopted (either Joey's
>> solution or our repair solution or any other solution). The primary
>> motivation is to have the repair embedded inside the open-source Cassandra
>> itself, so we can retire all various privately developed solutions
>> eventually :)
>>
>> I am also happy to help (drive conversation, discussion, etc.) in any way
>> to have a repair solution adopted inside Cassandra itself, please let me
>> know. Happy to help!
>>
>> Yours Faithfully,
>> Jaydeep
>>
>> On Mon, Jul 24, 2023 at 1:44 PM German Eichberger via dev <
>> dev@cassandra.apache.org> wrote:
>>
>> All,
>>
>> We had a brief discussion in [2] about the 

Re: [Discuss] Repair inside C*

[Jaydeep Chovatia]

Sounds good, German. Feel free to let me know if you need my help in filing
CEP, adding supporting content to the CEP, etc.
As I mentioned previously, I have already been working (going through an
internal review) on creating a one-pager doc, code, etc., that has been
working for us for the last six years at an immense scale, and I will share
it soon on a private fork.

Thanks,
Jaydeep

On Tue, Jul 25, 2023 at 9:48 AM German Eichberger via dev <
dev@cassandra.apache.org> wrote:

> In [2] we suggested that the next step should be a CEP.
>
> I am happy to lend a hand to this effort as well.
>
> Thanks Jaydeep and David - really appreciated.
>
> German
>
> --
> *From:* David Capwell 
> *Sent:* Tuesday, July 25, 2023 8:32 AM
> *To:* dev 
> *Cc:* German Eichberger 
> *Subject:* [EXTERNAL] Re: [Discuss] Repair inside C*
>
> As someone who has done a lot of work trying to make repair stable, I
> approve of this message ^_^
>
> More than glad to help mentor this work
>
> On Jul 24, 2023, at 6:29 PM, Jaydeep Chovatia 
> wrote:
>
> To clarify the repair solution timing, the one we have listed in the
> article is not the recently developed one. We were hitting some
> high-priority production challenges back in early 2018, and to address
> that, we developed and rolled out the solution in production in just a few
> months. The timing-wise, the solution was developed and productized by Q3
> 2018, of course, continued to evolve thereafter. Usually, we explore the
> existing solutions we can leverage, but when we started our journey in
> early 2018, most of the solutions were based on sidecar solutions. There is
> nothing against the sidecar solution; it was just a pure business decision,
> and in that, we wanted to avoid the sidecar to avoid a dependency on the
> control plane. Every solution developed has its deep context, merits, and
> pros and cons; they are all great solutions!
>
> An appeal to the community members is to think one more time about having
> repairs in the Open Source Cassandra itself. As mentioned in my previous
> email, any solution getting adopted is fine; the important aspect is to
> have a repair solution in the OSS Cassandra itself!
>
> Yours Faithfully,
> Jaydeep
>
> On Mon, Jul 24, 2023 at 3:46 PM Jaydeep Chovatia <
> chovatia.jayd...@gmail.com> wrote:
>
> Hi German,
>
> The goal is always to backport our learnings back to the community. For
> example, I have already successfully backported the following two
> enhancements/bug fixes back to the Open Source Cassandra, which are
> described in the article. I am already currently working on open-source a
> few more enhancements mentioned in the article back to the open-source.
>
>1. https://issues.apache.org/jira/browse/CASSANDRA-18555
>2. https://issues.apache.org/jira/browse/CASSANDRA-13740
>
> There is definitely heavy interest in having the repair solution inside
> the Open Source Cassandra itself, very much like Compaction. As I write
> this email, we are internally working on a one-pager proposal doc to all
> the community members on having a repair inside the OSS Apache Cassandra
> along with our private fork - I will share it soon.
>
> Generally, we are ok with any solution getting adopted (either Joey's
> solution or our repair solution or any other solution). The primary
> motivation is to have the repair embedded inside the open-source Cassandra
> itself, so we can retire all various privately developed solutions
> eventually :)
>
> I am also happy to help (drive conversation, discussion, etc.) in any way
> to have a repair solution adopted inside Cassandra itself, please let me
> know. Happy to help!
>
> Yours Faithfully,
> Jaydeep
>
> On Mon, Jul 24, 2023 at 1:44 PM German Eichberger via dev <
> dev@cassandra.apache.org> wrote:
>
> All,
>
> We had a brief discussion in [2] about the Uber article [1] where they
> talk about having integrated repair into Cassandra and how great that is. I
> expressed my disappointment that they didn't work with the community on
> that (Uber, if you are listening time to make amends ) and it turns out
> Joey already had the idea and wrote the code [3] - so I wanted to start a
> discussion to gauge interest and maybe how to revive that effort.
>
> Thanks,
> German
>
> [1]
> https://www.uber.com/blog/how-uber-optimized-cassandra-operations-at-scale/
> [2] https://the-asf.slack.com/archives/CK23JSY2K/p1690225062383619
> [3] https://issues.apache.org/jira/browse/CASSANDRA-14346
>
>
>

Re: Java distributed upgrade tests fail and issue with CircleCI generate.sh script

[Ekaterina Dimitrova]

1 of 2 is resolved.
The CircleCI script is fixed, you might want to rebase trunk.

On Tue, 25 Jul 2023 at 12:05, Ekaterina Dimitrova 
wrote:

> Hi all,
> All java distributed upgrade tests fail at the moment.
> Testing a potential fix in CASSANDRA-18690.
> Apologize for the issue.
> After this issue is fixed you should not be seeing any other failures than
> the SSLFactoryTest as pointed last night.
>
> Also, I added a small fix for generate.sh script which was silently
> ignoring the -e option and not detecting new/modified tests. It is also
> under testing in CASSANDRA-18255. Anyone is welcome to test it
>
> Apologies for the inconvenience caused. Both should be resolved today.
>
> Best regards,
> Ekaterina
>

Re: [Discuss] Repair inside C*

[German Eichberger via dev]

In [2] we suggested that the next step should be a CEP.

I am happy to lend a hand to this effort as well.

Thanks Jaydeep and David - really appreciated.

German


From: David Capwell 
Sent: Tuesday, July 25, 2023 8:32 AM
To: dev 
Cc: German Eichberger 
Subject: [EXTERNAL] Re: [Discuss] Repair inside C*

As someone who has done a lot of work trying to make repair stable, I approve 
of this message ^_^

More than glad to help mentor this work

On Jul 24, 2023, at 6:29 PM, Jaydeep Chovatia  
wrote:

To clarify the repair solution timing, the one we have listed in the article is 
not the recently developed one. We were hitting some high-priority production 
challenges back in early 2018, and to address that, we developed and rolled out 
the solution in production in just a few months. The timing-wise, the solution 
was developed and productized by Q3 2018, of course, continued to evolve 
thereafter. Usually, we explore the existing solutions we can leverage, but 
when we started our journey in early 2018, most of the solutions were based on 
sidecar solutions. There is nothing against the sidecar solution; it was just a 
pure business decision, and in that, we wanted to avoid the sidecar to avoid a 
dependency on the control plane. Every solution developed has its deep context, 
merits, and pros and cons; they are all great solutions!

An appeal to the community members is to think one more time about having 
repairs in the Open Source Cassandra itself. As mentioned in my previous email, 
any solution getting adopted is fine; the important aspect is to have a repair 
solution in the OSS Cassandra itself!

Yours Faithfully,
Jaydeep

On Mon, Jul 24, 2023 at 3:46 PM Jaydeep Chovatia 
mailto:chovatia.jayd...@gmail.com>> wrote:
Hi German,

The goal is always to backport our learnings back to the community. For 
example, I have already successfully backported the following two 
enhancements/bug fixes back to the Open Source Cassandra, which are described 
in the article. I am already currently working on open-source a few more 
enhancements mentioned in the article back to the open-source.

  1.  https://issues.apache.org/jira/browse/CASSANDRA-18555
  2.  https://issues.apache.org/jira/browse/CASSANDRA-13740

There is definitely heavy interest in having the repair solution inside the 
Open Source Cassandra itself, very much like Compaction. As I write this email, 
we are internally working on a one-pager proposal doc to all the community 
members on having a repair inside the OSS Apache Cassandra along with our 
private fork - I will share it soon.

Generally, we are ok with any solution getting adopted (either Joey's solution 
or our repair solution or any other solution). The primary motivation is to 
have the repair embedded inside the open-source Cassandra itself, so we can 
retire all various privately developed solutions eventually :)

I am also happy to help (drive conversation, discussion, etc.) in any way to 
have a repair solution adopted inside Cassandra itself, please let me know. 
Happy to help!

Yours Faithfully,
Jaydeep

On Mon, Jul 24, 2023 at 1:44 PM German Eichberger via dev 
mailto:dev@cassandra.apache.org>> wrote:
All,

We had a brief discussion in [2] about the Uber article [1] where they talk 
about having integrated repair into Cassandra and how great that is. I 
expressed my disappointment that they didn't work with the community on that 
(Uber, if you are listening time to make amends ) and it turns out Joey 
already had the idea and wrote the code [3] - so I wanted to start a discussion 
to gauge interest and maybe how to revive that effort.

Thanks,
German

[1] https://www.uber.com/blog/how-uber-optimized-cassandra-operations-at-scale/
[2] https://the-asf.slack.com/archives/CK23JSY2K/p1690225062383619
[3] https://issues.apache.org/jira/browse/CASSANDRA-14346

Java distributed upgrade tests fail and issue with CircleCI generate.sh script

[Ekaterina Dimitrova]

Hi all,
All java distributed upgrade tests fail at the moment.
Testing a potential fix in CASSANDRA-18690.
Apologize for the issue.
After this issue is fixed you should not be seeing any other failures than
the SSLFactoryTest as pointed last night.

Also, I added a small fix for generate.sh script which was silently
ignoring the -e option and not detecting new/modified tests. It is also
under testing in CASSANDRA-18255. Anyone is welcome to test it

Apologies for the inconvenience caused. Both should be resolved today.

Best regards,
Ekaterina

Re: [Discuss] Repair inside C*

[David Capwell]

As someone who has done a lot of work trying to make repair stable, I approve 
of this message ^_^

More than glad to help mentor this work

> On Jul 24, 2023, at 6:29 PM, Jaydeep Chovatia  
> wrote:
> 
> To clarify the repair solution timing, the one we have listed in the article 
> is not the recently developed one. We were hitting some high-priority 
> production challenges back in early 2018, and to address that, we developed 
> and rolled out the solution in production in just a few months. The 
> timing-wise, the solution was developed and productized by Q3 2018, of 
> course, continued to evolve thereafter. Usually, we explore the existing 
> solutions we can leverage, but when we started our journey in early 2018, 
> most of the solutions were based on sidecar solutions. There is nothing 
> against the sidecar solution; it was just a pure business decision, and in 
> that, we wanted to avoid the sidecar to avoid a dependency on the control 
> plane. Every solution developed has its deep context, merits, and pros and 
> cons; they are all great solutions! 
> 
> An appeal to the community members is to think one more time about having 
> repairs in the Open Source Cassandra itself. As mentioned in my previous 
> email, any solution getting adopted is fine; the important aspect is to have 
> a repair solution in the OSS Cassandra itself!
> 
> Yours Faithfully,
> Jaydeep
> 
> On Mon, Jul 24, 2023 at 3:46 PM Jaydeep Chovatia  > wrote:
>> Hi German,
>> 
>> The goal is always to backport our learnings back to the community. For 
>> example, I have already successfully backported the following two 
>> enhancements/bug fixes back to the Open Source Cassandra, which are 
>> described in the article. I am already currently working on open-source a 
>> few more enhancements mentioned in the article back to the open-source.
>> https://issues.apache.org/jira/browse/CASSANDRA-18555
>> https://issues.apache.org/jira/browse/CASSANDRA-13740
>> There is definitely heavy interest in having the repair solution inside the 
>> Open Source Cassandra itself, very much like Compaction. As I write this 
>> email, we are internally working on a one-pager proposal doc to all the 
>> community members on having a repair inside the OSS Apache Cassandra along 
>> with our private fork - I will share it soon.
>> 
>> Generally, we are ok with any solution getting adopted (either Joey's 
>> solution or our repair solution or any other solution). The primary 
>> motivation is to have the repair embedded inside the open-source Cassandra 
>> itself, so we can retire all various privately developed solutions 
>> eventually :)
>> 
>> I am also happy to help (drive conversation, discussion, etc.) in any way to 
>> have a repair solution adopted inside Cassandra itself, please let me know. 
>> Happy to help!
>> 
>> Yours Faithfully,
>> Jaydeep
>> 
>> On Mon, Jul 24, 2023 at 1:44 PM German Eichberger via dev 
>> mailto:dev@cassandra.apache.org>> wrote:
>>> All,
>>> 
>>> We had a brief discussion in [2] about the Uber article [1] where they talk 
>>> about having integrated repair into Cassandra and how great that is. I 
>>> expressed my disappointment that they didn't work with the community on 
>>> that (Uber, if you are listening time to make amends ) and it turns out 
>>> Joey already had the idea and wrote the code [3] - so I wanted to start a 
>>> discussion to gauge interest and maybe how to revive that effort.
>>> 
>>> Thanks,
>>> German
>>> 
>>> [1] 
>>> https://www.uber.com/blog/how-uber-optimized-cassandra-operations-at-scale/
>>> [2] https://the-asf.slack.com/archives/CK23JSY2K/p1690225062383619
>>> [3] https://issues.apache.org/jira/browse/CASSANDRA-14346

Re: [ANNOUNCEMENT] Expect failures today. Dropping JDK 8 and adding JDK 11

[Jeremiah Jordan]

 Yes.  Great to get this work merged.  Thanks to everyone who worked on it
and to Ekaterina for leading the charge!

-Jeremiah

On Jul 24, 2023 at 9:27:10 PM, C. Scott Andreas 
wrote:

> Ekaterina, thank you for spearheading JDK17 support for Apache Cassandra!
> Exciting to get to this point.
>
> - Scott
>
> On Jul 24, 2023, at 7:11 PM, Ekaterina Dimitrova 
> wrote:
>
> 
> Good news!
> After run #1638-39 you should not see anything else failing than
> SSLFactory test class. This known issue will be fixed by potentially adding
>  bounty castle. More info in CASSANDRA-17992 and this netty PR:
> https://github.com/netty/netty/issues/10317
> We can probably mark the test class with @Ignore, but knowing how easily
> those are forgotten and 17992 being already in review, I prefer not to do
> it.
>
> The only new failure I found in #1636 is a rare flaky test we never saw in
> CircleCI before. (unit tests were running only there; they were not enabled
> in Jenkins until we cleaned them ). Ticket already opened -
> CASSANDRA-18685 
>
> Last but not least, eclipse-warnings is already removed (it doesn't work
> with post JDK8 versions), but the new static analysis from Checker
> Framework is already in review and soon to land in trunk - CASSANDRA-18239
>
> As usual - if you have any questions or concerns, please do let me know.
> Last but not least - thank you to everyone who helped in one way or
> another with this effort!!
>
> On Mon, 24 Jul 2023 at 16:37, Ekaterina Dimitrova 
> wrote:
>
>> Ninja fix was required for Jenkins, new build started #1636
>>
>> On Mon, 24 Jul 2023 at 15:42, Ekaterina Dimitrova 
>> wrote:
>>
>>> Done!
>>>
>>> All commits from 18255 are in.
>>> The first run to monitor will be in Jenkins #1635
>>>
>>> There will be still fixes to be applied for some unit and in-jvm tests
>>> that were pending on the drop but I will do it when I see Jenkins kicking
>>> in this run properly.  (Which are those can be seen in CASSANDRA-16895,
>>> there is a table in its description)
>>>
>>> I will keep you posted on any new developments.
>>>
>>>
>>> On Mon, 24 Jul 2023 at 14:52, Ekaterina Dimitrova 
>>> wrote:
>>>
 Starting commits for 18255. Please put on hold any trunk commits. I
 will let you know when it is done. Thank you

 On Mon, 24 Jul 2023 at 11:29, Ekaterina Dimitrova <
 e.dimitr...@gmail.com> wrote:

> Hi everyone,
>
> Happy Monday!
>
> I am working on dropping JDK 8 and adding JDK17 on trunk in both CI
> systems today.
> This requires numerous patches in a few repos so you will be seeing
> more failures in CI throughout the day today, but it shouldn’t be anything
> more 爛 than what we have listed in the table of failures in
> CASSANDRA-16895’s description. I will be applying the fixes one by one
> today.
> I will keep you posted with updates. Also, please, do let me know if
> you have any questions or concerns.
>
> Best regards,
> Ekaterina
>
>
>