Keeping on top of test failures

[Joshua McKenzie]

(Taking #cassandra-dev slack chat to here)

For context, we have a long history of an ebb and flow of flaky test
failures building up and getting burned down, but don't really have a
workflow or discipline around having a clean snapshot of where we are or
attempting to stay at some kind of steady state. We have thousands of tests
executing in a wide variety of environments: this state is to be expected,
but I argue needs to be actively managed so we don't get into the kind of
situation we did with 4.0 again.

I threw together a couple of JIRA queries that paint a pretty navigable
picture IMO:

Total JIRA for test failures:
https://issues.apache.org/jira/issues/?filter=12350869&jql=project%20%3D%20Cassandra%20AND%20resolution%20%3D%20unresolved%20AND%20(summary%20~%20flaky%20OR%20summary%20~%20test%20OR%20component%20%3D%20%22Test%2Funit%22)%20AND%20type%20%3D%20bug%20AND%20issuekey%20not%20in%20(CASSANDRA-16010%2C%20CASSANDRA-16024%2C%20CASSANDRA-16022%2C%20CASSANDRA-16021%2C%20CASSANDRA-16025%2C%20CASSANDRA-16023)%20AND%20summary%20!~%20hardening%20ORDER%20BY%20cf%5B12313825%5D%20ASC
(sorry for the URL) - 112 failures

# of failures more recent than 6 months:
https://issues.apache.org/jira/issues/?filter=12350869
10 failures.

In the interest of tidying this up and staying on top of it going forward,
I propose the following:
1. We close as won't fix all test failures created >= 6 months ago (We had
a big push for 4.0 and a lot of this JIRA content is stale)
2. We switch the "Bug Category" for these 10 more recent to "Correctness -
Test Failure"
3. We document a "canonical" workflow around test failures that links to a
saved JIRA filter query that includes:
4. When you're working on something and you see a test failure that isn't
related to your patch, check that filter, see if the test name is there,
and if not create a new ticket w/that Bug Category

In theory this should give us a single source of truth for documented test
failures as well as an entry point for new contributors.

Thoughts?

~Josh

Re: Keeping on top of test failures

[Benjamin Lerer]

Thanks for the proposal Josh.
It sounds good to me.

Le jeu. 9 sept. 2021 à 17:32, Joshua McKenzie  a
écrit :

> (Taking #cassandra-dev slack chat to here)
>
> For context, we have a long history of an ebb and flow of flaky test
> failures building up and getting burned down, but don't really have a
> workflow or discipline around having a clean snapshot of where we are or
> attempting to stay at some kind of steady state. We have thousands of tests
> executing in a wide variety of environments: this state is to be expected,
> but I argue needs to be actively managed so we don't get into the kind of
> situation we did with 4.0 again.
>
> I threw together a couple of JIRA queries that paint a pretty navigable
> picture IMO:
>
> Total JIRA for test failures:
>
> https://issues.apache.org/jira/issues/?filter=12350869&jql=project%20%3D%20Cassandra%20AND%20resolution%20%3D%20unresolved%20AND%20(summary%20~%20flaky%20OR%20summary%20~%20test%20OR%20component%20%3D%20%22Test%2Funit%22)%20AND%20type%20%3D%20bug%20AND%20issuekey%20not%20in%20(CASSANDRA-16010%2C%20CASSANDRA-16024%2C%20CASSANDRA-16022%2C%20CASSANDRA-16021%2C%20CASSANDRA-16025%2C%20CASSANDRA-16023)%20AND%20summary%20!~%20hardening%20ORDER%20BY%20cf%5B12313825%5D%20ASC
> (sorry for the URL) - 112 failures
>
> # of failures more recent than 6 months:
> https://issues.apache.org/jira/issues/?filter=12350869
> 10 failures.
>
> In the interest of tidying this up and staying on top of it going forward,
> I propose the following:
> 1. We close as won't fix all test failures created >= 6 months ago (We had
> a big push for 4.0 and a lot of this JIRA content is stale)
> 2. We switch the "Bug Category" for these 10 more recent to "Correctness -
> Test Failure"
> 3. We document a "canonical" workflow around test failures that links to a
> saved JIRA filter query that includes:
> 4. When you're working on something and you see a test failure that isn't
> related to your patch, check that filter, see if the test name is there,
> and if not create a new ticket w/that Bug Category
>
> In theory this should give us a single source of truth for documented test
> failures as well as an entry point for new contributors.
>
> Thoughts?
>
> ~Josh
>

Re: Keeping on top of test failures

[Ekaterina Dimitrova]

Same here, +1, thank you!

On Thu, 9 Sep 2021 at 11:35, Benjamin Lerer  wrote:

> Thanks for the proposal Josh.
> It sounds good to me.
>
> Le jeu. 9 sept. 2021 à 17:32, Joshua McKenzie  a
> écrit :
>
> > (Taking #cassandra-dev slack chat to here)
> >
> > For context, we have a long history of an ebb and flow of flaky test
> > failures building up and getting burned down, but don't really have a
> > workflow or discipline around having a clean snapshot of where we are or
> > attempting to stay at some kind of steady state. We have thousands of
> tests
> > executing in a wide variety of environments: this state is to be
> expected,
> > but I argue needs to be actively managed so we don't get into the kind of
> > situation we did with 4.0 again.
> >
> > I threw together a couple of JIRA queries that paint a pretty navigable
> > picture IMO:
> >
> > Total JIRA for test failures:
> >
> >
> https://issues.apache.org/jira/issues/?filter=12350869&jql=project%20%3D%20Cassandra%20AND%20resolution%20%3D%20unresolved%20AND%20(summary%20~%20flaky%20OR%20summary%20~%20test%20OR%20component%20%3D%20%22Test%2Funit%22)%20AND%20type%20%3D%20bug%20AND%20issuekey%20not%20in%20(CASSANDRA-16010%2C%20CASSANDRA-16024%2C%20CASSANDRA-16022%2C%20CASSANDRA-16021%2C%20CASSANDRA-16025%2C%20CASSANDRA-16023)%20AND%20summary%20!~%20hardening%20ORDER%20BY%20cf%5B12313825%5D%20ASC
> > (sorry for the URL) - 112 failures
> >
> > # of failures more recent than 6 months:
> > https://issues.apache.org/jira/issues/?filter=12350869
> > 10 failures.
> >
> > In the interest of tidying this up and staying on top of it going
> forward,
> > I propose the following:
> > 1. We close as won't fix all test failures created >= 6 months ago (We
> had
> > a big push for 4.0 and a lot of this JIRA content is stale)
> > 2. We switch the "Bug Category" for these 10 more recent to "Correctness
> -
> > Test Failure"
> > 3. We document a "canonical" workflow around test failures that links to
> a
> > saved JIRA filter query that includes:
> > 4. When you're working on something and you see a test failure that isn't
> > related to your patch, check that filter, see if the test name is there,
> > and if not create a new ticket w/that Bug Category
> >
> > In theory this should give us a single source of truth for documented
> test
> > failures as well as an entry point for new contributors.
> >
> > Thoughts?
> >
> > ~Josh
> >
>

Re: Keeping on top of test failures

[Brandon Williams]

+1

On Thu, Sep 9, 2021 at 10:39 AM Joshua McKenzie  wrote:
>
> (Taking #cassandra-dev slack chat to here)
>
> For context, we have a long history of an ebb and flow of flaky test
> failures building up and getting burned down, but don't really have a
> workflow or discipline around having a clean snapshot of where we are or
> attempting to stay at some kind of steady state. We have thousands of tests
> executing in a wide variety of environments: this state is to be expected,
> but I argue needs to be actively managed so we don't get into the kind of
> situation we did with 4.0 again.
>
> I threw together a couple of JIRA queries that paint a pretty navigable
> picture IMO:
>
> Total JIRA for test failures:
> https://issues.apache.org/jira/issues/?filter=12350869&jql=project%20%3D%20Cassandra%20AND%20resolution%20%3D%20unresolved%20AND%20(summary%20~%20flaky%20OR%20summary%20~%20test%20OR%20component%20%3D%20%22Test%2Funit%22)%20AND%20type%20%3D%20bug%20AND%20issuekey%20not%20in%20(CASSANDRA-16010%2C%20CASSANDRA-16024%2C%20CASSANDRA-16022%2C%20CASSANDRA-16021%2C%20CASSANDRA-16025%2C%20CASSANDRA-16023)%20AND%20summary%20!~%20hardening%20ORDER%20BY%20cf%5B12313825%5D%20ASC
> (sorry for the URL) - 112 failures
>
> # of failures more recent than 6 months:
> https://issues.apache.org/jira/issues/?filter=12350869
> 10 failures.
>
> In the interest of tidying this up and staying on top of it going forward,
> I propose the following:
> 1. We close as won't fix all test failures created >= 6 months ago (We had
> a big push for 4.0 and a lot of this JIRA content is stale)
> 2. We switch the "Bug Category" for these 10 more recent to "Correctness -
> Test Failure"
> 3. We document a "canonical" workflow around test failures that links to a
> saved JIRA filter query that includes:
> 4. When you're working on something and you see a test failure that isn't
> related to your patch, check that filter, see if the test name is there,
> and if not create a new ticket w/that Bug Category
>
> In theory this should give us a single source of truth for documented test
> failures as well as an entry point for new contributors.
>
> Thoughts?
>
> ~Josh

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Keeping on top of test failures

[Andrés de la Peña]

+1, thanks for the proposal.

On Thu, 9 Sept 2021 at 16:45, Brandon Williams  wrote:

> +1
>
> On Thu, Sep 9, 2021 at 10:39 AM Joshua McKenzie 
> wrote:
> >
> > (Taking #cassandra-dev slack chat to here)
> >
> > For context, we have a long history of an ebb and flow of flaky test
> > failures building up and getting burned down, but don't really have a
> > workflow or discipline around having a clean snapshot of where we are or
> > attempting to stay at some kind of steady state. We have thousands of
> tests
> > executing in a wide variety of environments: this state is to be
> expected,
> > but I argue needs to be actively managed so we don't get into the kind of
> > situation we did with 4.0 again.
> >
> > I threw together a couple of JIRA queries that paint a pretty navigable
> > picture IMO:
> >
> > Total JIRA for test failures:
> >
> https://issues.apache.org/jira/issues/?filter=12350869&jql=project%20%3D%20Cassandra%20AND%20resolution%20%3D%20unresolved%20AND%20(summary%20~%20flaky%20OR%20summary%20~%20test%20OR%20component%20%3D%20%22Test%2Funit%22)%20AND%20type%20%3D%20bug%20AND%20issuekey%20not%20in%20(CASSANDRA-16010%2C%20CASSANDRA-16024%2C%20CASSANDRA-16022%2C%20CASSANDRA-16021%2C%20CASSANDRA-16025%2C%20CASSANDRA-16023)%20AND%20summary%20!~%20hardening%20ORDER%20BY%20cf%5B12313825%5D%20ASC
> > (sorry for the URL) - 112 failures
> >
> > # of failures more recent than 6 months:
> > https://issues.apache.org/jira/issues/?filter=12350869
> > 10 failures.
> >
> > In the interest of tidying this up and staying on top of it going
> forward,
> > I propose the following:
> > 1. We close as won't fix all test failures created >= 6 months ago (We
> had
> > a big push for 4.0 and a lot of this JIRA content is stale)
> > 2. We switch the "Bug Category" for these 10 more recent to "Correctness
> -
> > Test Failure"
> > 3. We document a "canonical" workflow around test failures that links to
> a
> > saved JIRA filter query that includes:
> > 4. When you're working on something and you see a test failure that isn't
> > related to your patch, check that filter, see if the test name is there,
> > and if not create a new ticket w/that Bug Category
> >
> > In theory this should give us a single source of truth for documented
> test
> > failures as well as an entry point for new contributors.
> >
> > Thoughts?
> >
> > ~Josh
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSS] CEP-7 Storage Attached Index

[Patrick McFadin]

+1 on introducing this in an incremental manner and after reading through
CASSANDRA-16092 that seems like a perfect place to start. I see that work
on that Jira has stopped until direction for CEP-7 has been voted in.

I say start the vote and let's get this really valuable developer feature
underway.

Patrick

On Tue, Sep 7, 2021 at 10:40 AM Caleb Rackliffe 
wrote:

> So this thread stalled almost a year ago. (Wow, time flies when you're
> trying to release 4.0.) My synthesis of the conversation to this point is
> that while there are some open questions about testing
> methodology/"definition of done" and our choice of particular on-disk data
> structures, neither of these should be a serious obstacle to moving forward
> w/ a vote. Having said that, is there anything left around the CEP that we
> feel should prevent it from moving to a vote?
>
> In terms of how we would proceed from the point a vote passes, it seems
> like there have been enough concerns around the proposed/necessary breaking
> changes to the 2i API, that we will start development by introducing
> components as incrementally as possible into a long-running feature branch
> off trunk. (This work would likely start w/ *CASSANDRA-16092*
> , which we could
> resolve as a sub-task of the SAI epic without interfering with other trunk
> development likely destined for a 4.x minor, etc.)
>
> On Thu, Sep 24, 2020 at 2:47 AM Jasonstack Zhao Yang <
> jasonstack.z...@gmail.com> wrote:
>
> > >> Question is: is this planned as a next step?
> > >> If yes, how are we going to mark SAI as experimental until it gets
> > >> row offsets? Also, it is likely that index format is going to change
> > when
> > >> row offsets are added, so my concern is that we may have to support
> two
> > >> versions of a format for a smooth migration.
> >
> > The goal is to support row-level index when merging SAI, I will update
> the
> > CEP about it.
> >
> > >> I think switching to row
> > >> offsets also has a huge impact on interaction with SPRC and has some
> > >> potential for optimisations.
> >
> > Can you share more details on the optimizations?
> >
> >
> >
> > On Thu, 24 Sep 2020 at 15:20, Oleksandr Petrov <
> oleksandr.pet...@gmail.com
> > >
> > wrote:
> >
> > > > But for improving overall index read performance, I think improving
> > base
> > > table read perf  (because SAI/SASI executes LOTS of
> > > SinglePartitionReadCommand after searching on-disk index) is more
> > effective
> > > than switching from Trie to Prefix BTree.
> > >
> > > I haven't suggested switching to Prefix B-Tree or any other structure,
> > the
> > > question was about rationale and motivation of picking one over the
> > other,
> > > which I am curious about for personal reasons/interests that lie
> outside
> > of
> > > Cassandra. Having this listed in CEP could have been helpful for future
> > > guidance. It's ok if this question is outside of the CEP scope.
> > >
> > > I also agree that there are many areas that require improvement around
> > the
> > > read/write path and 2i, many of which (even outside of base table
> format
> > or
> > > read perf) can yield positive performance results.
> > >
> > > > FWIW, I personally look forward to receiving that contribution when
> the
> > > time is right.
> > >
> > > I am very excited for this contribution, too, and it looks like very
> > solid
> > > work.
> > >
> > > I have one more question, about "Upon resolving partition keys, rows
> are
> > > loaded using Cassandra’s internal partition read command across
> SSTables
> > > and are post filtered". One of the criticisms of SASI and reasons for
> > > marking it as experimental was CASSANDRA-11990. I think switching to
> row
> > > offsets also has a huge impact on interaction with SPRC and has some
> > > potential for optimisations. Question is: is this planned as a next
> step?
> > > If yes, how are we going to mark SAI as experimental until it gets
> > > row offsets? Also, it is likely that index format is going to change
> when
> > > row offsets are added, so my concern is that we may have to support two
> > > versions of a format for a smooth migration.
> > >
> > >
> > >
> > > On Thu, Sep 24, 2020 at 6:53 AM Jasonstack Zhao Yang <
> > > jasonstack.z...@gmail.com> wrote:
> > >
> > > > >> I think CEP should be more upfront with "eventually replace
> > > > >>  it" bit, since it raises the question about what the people who
> are
> > > > using
> > > > >> other index implementations can expect.
> > > >
> > > > Will update the CEP to emphasize: SAI will replace other indexes.
> > > >
> > > > >> Unfortunately, I do not have an
> > > > >> implementation sitting around for a direct comparison, but I can
> > > imagine
> > > > >> situations when B-Trees may perform better because of simpler
> > > > construction.
> > > > >> Maybe we should even consider prototyping a prefix B-Tree to have
> a
> > > more
> > > > >> fair comparison.
> > > >
> > > > As long a

Re: Keeping on top of test failures

[Mick Semb Wever]

+1, much appreciated.


On 2021/09/09 16:03:31, Andrés de la Peña  wrote: 
> +1, thanks for the proposal.
> 
> On Thu, 9 Sept 2021 at 16:45, Brandon Williams  wrote:
> 
> > +1
> >
> > On Thu, Sep 9, 2021 at 10:39 AM Joshua McKenzie 
> > wrote:
> > >
> > > (Taking #cassandra-dev slack chat to here)
> > >
> > > For context, we have a long history of an ebb and flow of flaky test
> > > failures building up and getting burned down, but don't really have a
> > > workflow or discipline around having a clean snapshot of where we are or
> > > attempting to stay at some kind of steady state. We have thousands of
> > tests
> > > executing in a wide variety of environments: this state is to be
> > expected,
> > > but I argue needs to be actively managed so we don't get into the kind of
> > > situation we did with 4.0 again.
> > >
> > > I threw together a couple of JIRA queries that paint a pretty navigable
> > > picture IMO:
> > >
> > > Total JIRA for test failures:
> > >
> > https://issues.apache.org/jira/issues/?filter=12350869&jql=project%20%3D%20Cassandra%20AND%20resolution%20%3D%20unresolved%20AND%20(summary%20~%20flaky%20OR%20summary%20~%20test%20OR%20component%20%3D%20%22Test%2Funit%22)%20AND%20type%20%3D%20bug%20AND%20issuekey%20not%20in%20(CASSANDRA-16010%2C%20CASSANDRA-16024%2C%20CASSANDRA-16022%2C%20CASSANDRA-16021%2C%20CASSANDRA-16025%2C%20CASSANDRA-16023)%20AND%20summary%20!~%20hardening%20ORDER%20BY%20cf%5B12313825%5D%20ASC
> > > (sorry for the URL) - 112 failures
> > >
> > > # of failures more recent than 6 months:
> > > https://issues.apache.org/jira/issues/?filter=12350869
> > > 10 failures.
> > >
> > > In the interest of tidying this up and staying on top of it going
> > forward,
> > > I propose the following:
> > > 1. We close as won't fix all test failures created >= 6 months ago (We
> > had
> > > a big push for 4.0 and a lot of this JIRA content is stale)
> > > 2. We switch the "Bug Category" for these 10 more recent to "Correctness
> > -
> > > Test Failure"
> > > 3. We document a "canonical" workflow around test failures that links to
> > a
> > > saved JIRA filter query that includes:
> > > 4. When you're working on something and you see a test failure that isn't
> > > related to your patch, check that filter, see if the test name is there,
> > > and if not create a new ticket w/that Bug Category
> > >
> > > In theory this should give us a single source of truth for documented
> > test
> > > failures as well as an entry point for new contributors.
> > >
> > > Thoughts?
> > >
> > > ~Josh
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release dtest-api 0.0.9

[Mick Semb Wever]

+1

On Thu, 2 Sept 2021 at 13:20, Mick Semb Wever  wrote:
>
> Proposing the test build of in-jvm dtest API 0.0.9 for release.
>
> Repository: 
> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.9
>
> Candidate SHA: 
> https://github.com/apache/cassandra-in-jvm-dtest-api/commit/aa25319c3e0f506d19383db31d2974a7f5c58ab8
> tagged with 0.0.9
>
> Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1248/org/apache/cassandra/dtest-api/0.0.9/
>
> Key signature: A4C465FEA0C552561A392A61E91335D77E3E87CB
>
>
> Changes since last release:
>   * CASSANDRA-16803
> jvm-dtest-upgrade failing
> MixedModeReadTest.mixedModeReadColumnSubsetDigestCheck,
> ClassNotFoundException: com.vdurmont.semver4j.Semver
>
>
> The vote will be open for 24 hours. 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.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Keeping on top of test failures

[David Capwell]

+1

> On Sep 9, 2021, at 10:27 AM, Mick Semb Wever  wrote:
> 
> +1, much appreciated.
> 
> 
> On 2021/09/09 16:03:31, Andrés de la Peña  wrote: 
>> +1, thanks for the proposal.
>> 
>> On Thu, 9 Sept 2021 at 16:45, Brandon Williams  wrote:
>> 
>>> +1
>>> 
>>> On Thu, Sep 9, 2021 at 10:39 AM Joshua McKenzie 
>>> wrote:
 
 (Taking #cassandra-dev slack chat to here)
 
 For context, we have a long history of an ebb and flow of flaky test
 failures building up and getting burned down, but don't really have a
 workflow or discipline around having a clean snapshot of where we are or
 attempting to stay at some kind of steady state. We have thousands of
>>> tests
 executing in a wide variety of environments: this state is to be
>>> expected,
 but I argue needs to be actively managed so we don't get into the kind of
 situation we did with 4.0 again.
 
 I threw together a couple of JIRA queries that paint a pretty navigable
 picture IMO:
 
 Total JIRA for test failures:
 
>>> https://issues.apache.org/jira/issues/?filter=12350869&jql=project%20%3D%20Cassandra%20AND%20resolution%20%3D%20unresolved%20AND%20(summary%20~%20flaky%20OR%20summary%20~%20test%20OR%20component%20%3D%20%22Test%2Funit%22)%20AND%20type%20%3D%20bug%20AND%20issuekey%20not%20in%20(CASSANDRA-16010%2C%20CASSANDRA-16024%2C%20CASSANDRA-16022%2C%20CASSANDRA-16021%2C%20CASSANDRA-16025%2C%20CASSANDRA-16023)%20AND%20summary%20!~%20hardening%20ORDER%20BY%20cf%5B12313825%5D%20ASC
 (sorry for the URL) - 112 failures
 
 # of failures more recent than 6 months:
 https://issues.apache.org/jira/issues/?filter=12350869
 10 failures.
 
 In the interest of tidying this up and staying on top of it going
>>> forward,
 I propose the following:
 1. We close as won't fix all test failures created >= 6 months ago (We
>>> had
 a big push for 4.0 and a lot of this JIRA content is stale)
 2. We switch the "Bug Category" for these 10 more recent to "Correctness
>>> -
 Test Failure"
 3. We document a "canonical" workflow around test failures that links to
>>> a
 saved JIRA filter query that includes:
 4. When you're working on something and you see a test failure that isn't
 related to your patch, check that filter, see if the test name is there,
 and if not create a new ticket w/that Bug Category
 
 In theory this should give us a single source of truth for documented
>>> test
 failures as well as an entry point for new contributors.
 
 Thoughts?
 
 ~Josh
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>>> 
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release dtest-api 0.0.9

[David Capwell]

+1

> On Sep 9, 2021, at 1:52 PM, Mick Semb Wever  wrote:
> 
> +1
> 
> On Thu, 2 Sept 2021 at 13:20, Mick Semb Wever  wrote:
>> 
>> Proposing the test build of in-jvm dtest API 0.0.9 for release.
>> 
>> Repository: 
>> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.9
>> 
>> Candidate SHA: 
>> https://github.com/apache/cassandra-in-jvm-dtest-api/commit/aa25319c3e0f506d19383db31d2974a7f5c58ab8
>> tagged with 0.0.9
>> 
>> Artifacts: 
>> https://repository.apache.org/content/repositories/orgapachecassandra-1248/org/apache/cassandra/dtest-api/0.0.9/
>> 
>> Key signature: A4C465FEA0C552561A392A61E91335D77E3E87CB
>> 
>> 
>> Changes since last release:
>>  * CASSANDRA-16803
>> jvm-dtest-upgrade failing
>> MixedModeReadTest.mixedModeReadColumnSubsetDigestCheck,
>> ClassNotFoundException: com.vdurmont.semver4j.Semver
>> 
>> 
>> The vote will be open for 24 hours. 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.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

[DISCUSS] Java 17 support - Nashorn removed

[Ekaterina Dimitrova]

Hi team,

I started some initial work on the Java 17 support (CASSANDRA-16895).

One of the first observations is that Nashorn, which was already deprecated
in Java 11, is already fully removed. We use it for UDFs and one short
script 
in build.xml. The solution to that is to introduce graal as a dependency.
While graaljs is under UPL license, which is accepted by Apache, I believe
we also need the graal-sdk[2] which is under GPL2 which is not compatible
with Apache License, version 2.0. (Thanks Brandon for pointing that out)

For reference:

[1] https://www.graalvm.org/reference-manual/js/NashornMigrationGuide/

[2] https://github.com/oracle/graaljs/blob/master/docs/user/RunOnJDK.md

[3] https://ant.apache.org/manual/Tasks/script.html

[4]  https://www.apache.org/licenses/GPL-compatibility.html

At this point, I haven’t found any other substitution for Nashorn that can
fit our needs and while the build.xml issue can be possibly easily solved(I
guess), I am wondering what would be the right approach for the UDFs.

I am wondering what others think about that. Any
thoughts/experience/suggestions?

Best regards,

Ekaterina

Re: [VOTE] Release dtest-api 0.0.9

[C. Scott Andreas]

+1nb

> 
> On Sep 9, 2021, at 2:03 PM, David Capwell  wrote:
> 
> +1
> 
>> On Sep 9, 2021, at 1:52 PM, Mick Semb Wever  wrote:
>> 
>> +1
>> 
>>> On Thu, 2 Sept 2021 at 13:20, Mick Semb Wever  wrote:
>>> 
>>> Proposing the test build of in-jvm dtest API 0.0.9 for release.
>>> 
>>> Repository: 
>>> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.9
>>> 
>>> Candidate SHA: 
>>> https://github.com/apache/cassandra-in-jvm-dtest-api/commit/aa25319c3e0f506d19383db31d2974a7f5c58ab8
>>> tagged with 0.0.9
>>> 
>>> Artifacts: 
>>> https://repository.apache.org/content/repositories/orgapachecassandra-1248/org/apache/cassandra/dtest-api/0.0.9/
>>> 
>>> Key signature: A4C465FEA0C552561A392A61E91335D77E3E87CB
>>> 
>>> 
>>> Changes since last release:
>>> * CASSANDRA-16803
>>> jvm-dtest-upgrade failing
>>> MixedModeReadTest.mixedModeReadColumnSubsetDigestCheck,
>>> ClassNotFoundException: com.vdurmont.semver4j.Semver
>>> 
>>> 
>>> The vote will be open for 24 hours. 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.
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release dtest-api 0.0.9

[Ekaterina Dimitrova]

+1

On Thu, 9 Sep 2021 at 17:34, C. Scott Andreas  wrote:

> +1nb
>
> >
> > On Sep 9, 2021, at 2:03 PM, David Capwell 
> wrote:
> >
> > +1
> >
> >> On Sep 9, 2021, at 1:52 PM, Mick Semb Wever  wrote:
> >>
> >> +1
> >>
> >>> On Thu, 2 Sept 2021 at 13:20, Mick Semb Wever  wrote:
> >>>
> >>> Proposing the test build of in-jvm dtest API 0.0.9 for release.
> >>>
> >>> Repository:
> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.9
> >>>
> >>> Candidate SHA:
> https://github.com/apache/cassandra-in-jvm-dtest-api/commit/aa25319c3e0f506d19383db31d2974a7f5c58ab8
> >>> tagged with 0.0.9
> >>>
> >>> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1248/org/apache/cassandra/dtest-api/0.0.9/
> >>>
> >>> Key signature: A4C465FEA0C552561A392A61E91335D77E3E87CB
> >>>
> >>>
> >>> Changes since last release:
> >>> * CASSANDRA-16803
> >>> jvm-dtest-upgrade failing
> >>> MixedModeReadTest.mixedModeReadColumnSubsetDigestCheck,
> >>> ClassNotFoundException: com.vdurmont.semver4j.Semver
> >>>
> >>>
> >>> The vote will be open for 24 hours. 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.
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Release dtest-api 0.0.9

[Paulo Motta]

+1

On Thu, 9 Sep 2021 at 18:38 Ekaterina Dimitrova 
wrote:

> +1
>
> On Thu, 9 Sep 2021 at 17:34, C. Scott Andreas 
> wrote:
>
> > +1nb
> >
> > >
> > > On Sep 9, 2021, at 2:03 PM, David Capwell 
> > wrote:
> > >
> > > +1
> > >
> > >> On Sep 9, 2021, at 1:52 PM, Mick Semb Wever  wrote:
> > >>
> > >> +1
> > >>
> > >>> On Thu, 2 Sept 2021 at 13:20, Mick Semb Wever 
> wrote:
> > >>>
> > >>> Proposing the test build of in-jvm dtest API 0.0.9 for release.
> > >>>
> > >>> Repository:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.9
> > >>>
> > >>> Candidate SHA:
> >
> https://github.com/apache/cassandra-in-jvm-dtest-api/commit/aa25319c3e0f506d19383db31d2974a7f5c58ab8
> > >>> tagged with 0.0.9
> > >>>
> > >>> Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1248/org/apache/cassandra/dtest-api/0.0.9/
> > >>>
> > >>> Key signature: A4C465FEA0C552561A392A61E91335D77E3E87CB
> > >>>
> > >>>
> > >>> Changes since last release:
> > >>> * CASSANDRA-16803
> > >>> jvm-dtest-upgrade failing
> > >>> MixedModeReadTest.mixedModeReadColumnSubsetDigestCheck,
> > >>> ClassNotFoundException: com.vdurmont.semver4j.Semver
> > >>>
> > >>>
> > >>> The vote will be open for 24 hours. 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.
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >>
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: [VOTE] Release dtest-api 0.0.9

[Yifan Cai]

+1


- Yifan

> On Sep 9, 2021, at 3:04 PM, Paulo Motta  wrote:
> 
> +1
> 
>> On Thu, 9 Sep 2021 at 18:38 Ekaterina Dimitrova 
>> wrote:
>> 
>> +1
>> 
>> On Thu, 9 Sep 2021 at 17:34, C. Scott Andreas 
>> wrote:
>> 
>>> +1nb
>>> 
 
 On Sep 9, 2021, at 2:03 PM, David Capwell 
>>> wrote:
 
 +1
 
> On Sep 9, 2021, at 1:52 PM, Mick Semb Wever  wrote:
> 
> +1
> 
>> On Thu, 2 Sept 2021 at 13:20, Mick Semb Wever 
>> wrote:
>> 
>> Proposing the test build of in-jvm dtest API 0.0.9 for release.
>> 
>> Repository:
>>> 
>> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.9
>> 
>> Candidate SHA:
>>> 
>> https://github.com/apache/cassandra-in-jvm-dtest-api/commit/aa25319c3e0f506d19383db31d2974a7f5c58ab8
>> tagged with 0.0.9
>> 
>> Artifacts:
>>> 
>> https://repository.apache.org/content/repositories/orgapachecassandra-1248/org/apache/cassandra/dtest-api/0.0.9/
>> 
>> Key signature: A4C465FEA0C552561A392A61E91335D77E3E87CB
>> 
>> 
>> Changes since last release:
>> * CASSANDRA-16803
>> jvm-dtest-upgrade failing
>> MixedModeReadTest.mixedModeReadColumnSubsetDigestCheck,
>> ClassNotFoundException: com.vdurmont.semver4j.Semver
>> 
>> 
>> The vote will be open for 24 hours. 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.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
 For additional commands, e-mail: dev-h...@cassandra.apache.org
 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>>> 
>> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

[RESULT][VOTE] Release dtest-api 0.0.9

[Mick Semb Wever]

> Proposing the test build of in-jvm dtest API 0.0.9 for release.
>


Vote passes with 8  +1s (3 binding) and no vetoes.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org