Re: [VOTE] Release Apache Cassandra 4.0-beta1
+1 (non-binding) Short Jepsen tests with crash injection for map, set, counter, batch, and LWT passed. https://github.com/scalar-labs/scalar-jepsen 2020年7月15日(水) 8:06 Mick Semb Wever : > Proposing the test build of Cassandra 4.0-beta1 for release. > > sha1: 5e767711360ecc4bc05a7cd219f0e680bfada004 > Git: > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta1-tentative > Maven Artifacts: > > https://repository.apache.org/content/repositories/orgapachecassandra-1210/org/apache/cassandra/cassandra-all/4.0-beta1/ > > 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-beta1/ > > The vote will be open for 72 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 -1s. > > Eventual publishing and announcement of the 4.0-beta1 release will be > coordinated, as described in > > https://lists.apache.org/thread.html/r537fe799e7d5e6d72ac791fdbe9098ef0344c55400c7f68ff65abe51%40%3Cdev.cassandra.apache.org%3E > > [1]: CHANGES.txt: > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-beta1-tentative > [2]: NEWS.txt: > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta1-tentative >
Re: [DISCUSS] Revisiting Java 11's experimental status
Yea, ZGC is kinda tricky in 11. — Robert Stupp @snazy > On 14. Jul 2020, at 15:02, Jeff Jirsa wrote: > > Zgc > >> On Jul 14, 2020, at 2:26 AM, Robert Stupp wrote: >> >> >>> On 14. Jul 2020, at 07:33, Jeff Jirsa wrote: >>> >>> Perhaps the most notable parts of jdk11 (for cassandra) aren’t even prod >>> ready in jdk11 , so what’s the motivation and what does the project gain >>> from revisiting the experimental designation on jdk11? >> >> Can you elaborate on what’s not even prod ready in Java 11? > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org >
Re: [DISCUSS] A point of view on Testing Cassandra
> > This section reads as very anti-adding tests to test/unit; I am 100% in > favor of improving/creating our smoke, integration, regression, > performance, E2E, etc. testing, but don't think I am as negative to > test/unit, these tests are still valuable and more are welcome. I am a strong proponent of unit tests; upon re-reading the document I don't draw the same conclusion you do about the implications of the verbiage, however it's completely reasonable to have a point of view that's skeptical of people on this project's dedication to rigor and quality. :) I think it's critical to "name and tame" the current architectural constraints that undermine our ability to thoroughly unit test, as well as understand and mitigate the weaknesses of our current unit testing capabilities. A discrete example - attempting to "unit test" anything in the CommitLog largely leads to the entire CommitLog package spinning up, which drags in other packages, and before you know it you have multiple modules up and running thanks to the dependency tree. This is something myself, Jason, Stupp, Branimir, and others have all repeatedly burned time on trying to delicately walk through re: test spin up and tear down. This has ramifications far beyond just the time lost by engineers; the opportunity cost of that combined with the fragility of systems means that what testing we *do* perform is going to be constrained in scope relative to a traditional battery against a stand-alone, modularized artifact. Any and all contribution to *any* testing is strongly welcomed by all of us on the project. In terms of "where I and a few others are going to choose to invest our efforts" right now, accepting the current shortcomings of the system to make as much headway on the urgent + important is where we're headed. I think it's more important that we set a standard for the project (e.g., > fundamental conformance to properties of the database) rather than > attempting to measure quality relative to other DBs I'm sympathetic to this then the pragmatist in me hammers me down. In general, the adage "Software is never done; it is only released" resonates for me as the core of what we have to navigate here. We will never be able to state with 100% certainty that there is fundamental conformance to the availability and correctness properties of the database; this dissatisfying reality is why you have multiple teams implementing the software for spacecraft and then redundancies within redundancies in each system for unexpected failure scenarios and the unknown-unknown. In my opinion, we need a very clear articulation of our Definition of Done when it comes to correctness guarantees (yes Ariel, you were right) as well as a more skillful and deliberate articulated and implemented "failsafe" for catching things and/or surfacing adverse conditions within the system upon failure. It's tricky because in the past (in my opinion) we've been pretty remiss as a project when it comes to a devotion to correctness and rigor. The danger I'm anecdotally seeing is that if we let that pendulum swing too far in the other direction without successfully clearly defining what "Done" looks like from a quality perspective, that's an Everest we can all climb and die on as a project. On Wed, Jul 15, 2020 at 12:42 AM Scott Andreas wrote: > Thanks for starting discussion! > > Replying to the thread with what I would have left as comments. > > –– > > > As yet, we lack empirical evidence to quantify the relative stability or > instability of our project compared to a peer cohort > > I think it's more important that we set a standard for the project (e.g., > fundamental conformance to properties of the database) rather than > attempting to measure quality relative to other DBs. That might be a useful > measure, but I don't think it's the most important one. With regard to > measuring against a common standard in the project, this is roughly what I > had in mind when proposing "Release Quality Metrics" on the list in 2018. I > still think making progress on something like this is essential toward > defining a quantitative bar for release: > https://www.mail-archive.com/dev@cassandra.apache.org/msg13154.html > > > Conversely, the ability to repeatedly and thoroughly validate the > correctness of both new and existing functionality in the system is vital > to the speed with which we can evolve it's form and function. > > Strongly agreed. > > > Utopia (and following section) > > Some nods to great potential refactors to consider post-4.0 here. ^ > > > We should productize a kubernetes-centric, infra agnostic tool that has > the following available testing paradigms: > > This would be an excellent set of capabilities to have. > > > We need to empower our user community to participate in the testing > process... > > I really like this point. I took as a thought experiment "what would feel > great to be able to say" if one were to write a product announcement for > 4.0 and lande
Re: [VOTE] Release Apache Cassandra 4.0-beta1
+1 (non-binding) I've run the drivers smoke test suite and build jobs look good (there's 1 test failure that is not related to the server build): https://ci.appveyor.com/project/DataStax/cassandra-drivers-smoke-test/builds/34108936 Mick Semb Wever escreveu no dia quarta, 15/07/2020 à(s) 00:06: > Proposing the test build of Cassandra 4.0-beta1 for release. > > sha1: 5e767711360ecc4bc05a7cd219f0e680bfada004 > Git: > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta1-tentative > Maven Artifacts: > > https://repository.apache.org/content/repositories/orgapachecassandra-1210/org/apache/cassandra/cassandra-all/4.0-beta1/ > > 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-beta1/ > > The vote will be open for 72 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 -1s. > > Eventual publishing and announcement of the 4.0-beta1 release will be > coordinated, as described in > > https://lists.apache.org/thread.html/r537fe799e7d5e6d72ac791fdbe9098ef0344c55400c7f68ff65abe51%40%3Cdev.cassandra.apache.org%3E > > [1]: CHANGES.txt: > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-beta1-tentative > [2]: NEWS.txt: > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta1-tentative >
Re: [VOTE] Release Apache Cassandra 4.0-beta1
+1 (binding) On Wed, Jul 15, 2020 at 3:33 AM Yuji Ito wrote: > +1 (non-binding) > > Short Jepsen tests with crash injection for map, set, counter, batch, and > LWT passed. > https://github.com/scalar-labs/scalar-jepsen > > 2020年7月15日(水) 8:06 Mick Semb Wever : > > > Proposing the test build of Cassandra 4.0-beta1 for release. > > > > sha1: 5e767711360ecc4bc05a7cd219f0e680bfada004 > > Git: > > > > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta1-tentative > > Maven Artifacts: > > > > > https://repository.apache.org/content/repositories/orgapachecassandra-1210/org/apache/cassandra/cassandra-all/4.0-beta1/ > > > > 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-beta1/ > > > > The vote will be open for 72 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 > -1s. > > > > Eventual publishing and announcement of the 4.0-beta1 release will be > > coordinated, as described in > > > > > https://lists.apache.org/thread.html/r537fe799e7d5e6d72ac791fdbe9098ef0344c55400c7f68ff65abe51%40%3Cdev.cassandra.apache.org%3E > > > > [1]: CHANGES.txt: > > > > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-beta1-tentative > > [2]: NEWS.txt: > > > > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta1-tentative > > >
Re: [VOTE] Release Apache Cassandra 4.0-beta1
+1 (non-binding) On Wed, 15 Jul 2020 at 11:50, Joshua McKenzie wrote: > +1 (binding) > > On Wed, Jul 15, 2020 at 3:33 AM Yuji Ito wrote: > > > +1 (non-binding) > > > > Short Jepsen tests with crash injection for map, set, counter, batch, and > > LWT passed. > > https://github.com/scalar-labs/scalar-jepsen > > > > 2020年7月15日(水) 8:06 Mick Semb Wever : > > > > > Proposing the test build of Cassandra 4.0-beta1 for release. > > > > > > sha1: 5e767711360ecc4bc05a7cd219f0e680bfada004 > > > Git: > > > > > > > > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta1-tentative > > > Maven Artifacts: > > > > > > > > > https://repository.apache.org/content/repositories/orgapachecassandra-1210/org/apache/cassandra/cassandra-all/4.0-beta1/ > > > > > > 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-beta1/ > > > > > > The vote will be open for 72 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 > > -1s. > > > > > > Eventual publishing and announcement of the 4.0-beta1 release will be > > > coordinated, as described in > > > > > > > > > https://lists.apache.org/thread.html/r537fe799e7d5e6d72ac791fdbe9098ef0344c55400c7f68ff65abe51%40%3Cdev.cassandra.apache.org%3E > > > > > > [1]: CHANGES.txt: > > > > > > > > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-beta1-tentative > > > [2]: NEWS.txt: > > > > > > > > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta1-tentative > > > > > >
Re: [VOTE] Release Apache Cassandra 4.0-beta1
+1 (binding) On Wed, Jul 15, 2020 at 11:50 AM Joshua McKenzie wrote: > +1 (binding) > > On Wed, Jul 15, 2020 at 3:33 AM Yuji Ito wrote: > > > +1 (non-binding) > > > > Short Jepsen tests with crash injection for map, set, counter, batch, and > > LWT passed. > > https://github.com/scalar-labs/scalar-jepsen > > > > 2020年7月15日(水) 8:06 Mick Semb Wever : > > > > > Proposing the test build of Cassandra 4.0-beta1 for release. > > > > > > sha1: 5e767711360ecc4bc05a7cd219f0e680bfada004 > > > Git: > > > > > > > > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta1-tentative > > > Maven Artifacts: > > > > > > > > > https://repository.apache.org/content/repositories/orgapachecassandra-1210/org/apache/cassandra/cassandra-all/4.0-beta1/ > > > > > > 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-beta1/ > > > > > > The vote will be open for 72 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 > > -1s. > > > > > > Eventual publishing and announcement of the 4.0-beta1 release will be > > > coordinated, as described in > > > > > > > > > https://lists.apache.org/thread.html/r537fe799e7d5e6d72ac791fdbe9098ef0344c55400c7f68ff65abe51%40%3Cdev.cassandra.apache.org%3E > > > > > > [1]: CHANGES.txt: > > > > > > > > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-beta1-tentative > > > [2]: NEWS.txt: > > > > > > > > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta1-tentative > > > > > > -- http://twitter.com/tjake
Re: [DISCUSS] A point of view on Testing Cassandra
Perhaps you could clarify what you personally hope we _should_ agree as a project, and what you want us to _not_ agree (blossom in infinite variety)? My view: We need to agree a shared framework for quality going forwards. This will raise the bar to contributions, including above many that already exist. So, we then need a roadmap to meeting the framework's requirements for past and future contributions, so that feature development does not suffer too greatly from the extra expectations imposed upon them. I hope the framework and roadmap will be very specific and prescriptive in setting their minimum standards, which can of course be further augmented as any contributor desires. This seems to be the only way to come to an agreement about the point of contention you raise: some people perceive an insufficient concern about quality, others perceive a surplus of concern about quality. Until we agree quite specifically what we mean, this tension will persist. I also think it's a great way to improve project efficiency, if a contributor so cares: resources can be focused on the shared requirements first, since they're the "table stakes". Could you elaborate what you would prefer to leave out of this in your "Definition of Done"? On 15/07/2020, 16:28, "Joshua McKenzie" wrote: > > This section reads as very anti-adding tests to test/unit; I am 100% in > favor of improving/creating our smoke, integration, regression, > performance, E2E, etc. testing, but don't think I am as negative to > test/unit, these tests are still valuable and more are welcome. I am a strong proponent of unit tests; upon re-reading the document I don't draw the same conclusion you do about the implications of the verbiage, however it's completely reasonable to have a point of view that's skeptical of people on this project's dedication to rigor and quality. :) I think it's critical to "name and tame" the current architectural constraints that undermine our ability to thoroughly unit test, as well as understand and mitigate the weaknesses of our current unit testing capabilities. A discrete example - attempting to "unit test" anything in the CommitLog largely leads to the entire CommitLog package spinning up, which drags in other packages, and before you know it you have multiple modules up and running thanks to the dependency tree. This is something myself, Jason, Stupp, Branimir, and others have all repeatedly burned time on trying to delicately walk through re: test spin up and tear down. This has ramifications far beyond just the time lost by engineers; the opportunity cost of that combined with the fragility of systems means that what testing we *do* perform is going to be constrained in scope relative to a traditional battery against a stand-alone, modularized artifact. Any and all contribution to *any* testing is strongly welcomed by all of us on the project. In terms of "where I and a few others are going to choose to invest our efforts" right now, accepting the current shortcomings of the system to make as much headway on the urgent + important is where we're headed. I think it's more important that we set a standard for the project (e.g., > fundamental conformance to properties of the database) rather than > attempting to measure quality relative to other DBs I'm sympathetic to this then the pragmatist in me hammers me down. In general, the adage "Software is never done; it is only released" resonates for me as the core of what we have to navigate here. We will never be able to state with 100% certainty that there is fundamental conformance to the availability and correctness properties of the database; this dissatisfying reality is why you have multiple teams implementing the software for spacecraft and then redundancies within redundancies in each system for unexpected failure scenarios and the unknown-unknown. In my opinion, we need a very clear articulation of our Definition of Done when it comes to correctness guarantees (yes Ariel, you were right) as well as a more skillful and deliberate articulated and implemented "failsafe" for catching things and/or surfacing adverse conditions within the system upon failure. It's tricky because in the past (in my opinion) we've been pretty remiss as a project when it comes to a devotion to correctness and rigor. The danger I'm anecdotally seeing is that if we let that pendulum swing too far in the other direction without successfully clearly defining what "Done" looks like from a quality perspective, that's an Everest we can all climb and die on as a project. On Wed, Jul 15, 2020 at 12:42 AM Scott Andreas wrote: > Thanks for starting discussion! > > Replying to the thread with what I would have left as comments. > > –– > > > As ye
Re: [VOTE] Release Apache Cassandra 4.0-beta1
+1 (non-binding) On Wed, 15 Jul 2020 at 16:53, Jake Luciani wrote: > +1 (binding) > > On Wed, Jul 15, 2020 at 11:50 AM Joshua McKenzie > wrote: > > > +1 (binding) > > > > On Wed, Jul 15, 2020 at 3:33 AM Yuji Ito wrote: > > > > > +1 (non-binding) > > > > > > Short Jepsen tests with crash injection for map, set, counter, batch, > and > > > LWT passed. > > > https://github.com/scalar-labs/scalar-jepsen > > > > > > 2020年7月15日(水) 8:06 Mick Semb Wever : > > > > > > > Proposing the test build of Cassandra 4.0-beta1 for release. > > > > > > > > sha1: 5e767711360ecc4bc05a7cd219f0e680bfada004 > > > > Git: > > > > > > > > > > > > > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta1-tentative > > > > Maven Artifacts: > > > > > > > > > > > > > > https://repository.apache.org/content/repositories/orgapachecassandra-1210/org/apache/cassandra/cassandra-all/4.0-beta1/ > > > > > > > > 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-beta1/ > > > > > > > > The vote will be open for 72 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 > > > -1s. > > > > > > > > Eventual publishing and announcement of the 4.0-beta1 release will be > > > > coordinated, as described in > > > > > > > > > > > > > > https://lists.apache.org/thread.html/r537fe799e7d5e6d72ac791fdbe9098ef0344c55400c7f68ff65abe51%40%3Cdev.cassandra.apache.org%3E > > > > > > > > [1]: CHANGES.txt: > > > > > > > > > > > > > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-beta1-tentative > > > > [2]: NEWS.txt: > > > > > > > > > > > > > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta1-tentative > > > > > > > > > > > > -- > http://twitter.com/tjake >
Re: [VOTE] Release Apache Cassandra 4.0-beta1
+1 (binding) On Tue, Jul 14, 2020, 6:06 PM Mick Semb Wever wrote: > Proposing the test build of Cassandra 4.0-beta1 for release. > > sha1: 5e767711360ecc4bc05a7cd219f0e680bfada004 > Git: > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta1-tentative > Maven Artifacts: > > https://repository.apache.org/content/repositories/orgapachecassandra-1210/org/apache/cassandra/cassandra-all/4.0-beta1/ > > 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-beta1/ > > The vote will be open for 72 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 -1s. > > Eventual publishing and announcement of the 4.0-beta1 release will be > coordinated, as described in > > https://lists.apache.org/thread.html/r537fe799e7d5e6d72ac791fdbe9098ef0344c55400c7f68ff65abe51%40%3Cdev.cassandra.apache.org%3E > > [1]: CHANGES.txt: > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-beta1-tentative > [2]: NEWS.txt: > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta1-tentative >
Re: [VOTE] Release Apache Cassandra 4.0-beta1
+1 (nb) On Thu, 16 Jul 2020 at 01:28, Brandon Williams wrote: > +1 (binding) > > On Tue, Jul 14, 2020, 6:06 PM Mick Semb Wever wrote: > > > Proposing the test build of Cassandra 4.0-beta1 for release. > > > > sha1: 5e767711360ecc4bc05a7cd219f0e680bfada004 > > Git: > > > > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta1-tentative > > Maven Artifacts: > > > > > https://repository.apache.org/content/repositories/orgapachecassandra-1210/org/apache/cassandra/cassandra-all/4.0-beta1/ > > > > 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-beta1/ > > > > The vote will be open for 72 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 > -1s. > > > > Eventual publishing and announcement of the 4.0-beta1 release will be > > coordinated, as described in > > > > > https://lists.apache.org/thread.html/r537fe799e7d5e6d72ac791fdbe9098ef0344c55400c7f68ff65abe51%40%3Cdev.cassandra.apache.org%3E > > > > [1]: CHANGES.txt: > > > > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-beta1-tentative > > [2]: NEWS.txt: > > > > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta1-tentative > > >
Re: [VOTE] Release Apache Cassandra 3.11.7
+1 On Tue, Jul 14, 2020 at 5:47 PM Mick Semb Wever wrote: > > Proposing the test build of Cassandra 3.11.7 for release. > > sha1: 9fe62b3e40147fda2cc081744bd375b04574aef7 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.7-tentative > Maven Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-1209/org/apache/cassandra/cassandra-all/3.11.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/3.11.7/ > > The vote will be open for 72 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. > > [1]: CHANGES.txt: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.7-tentative > [2]: NEWS.txt: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.7-tentative -- Eric Evans eev...@apache.org - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] A point of view on Testing Cassandra
I like that the "we need a Definition of Done" seems to be surfacing. No directed intent from opening this thread but it seems a serendipitous outcome. And to reiterate - I didn't open this thread with the hope or intent of getting all of us to agree on anything or explore what we should or shouldn't agree on. That's not my place nor is it historically how we seem to operate. :) Just looking to share a PoV so other project participants know about some work coming down the pipe and can engage if they're interested. Brainstorming here to get discussion started, which we could drop in a doc and riff on or high bandwidth w/collaborators interested in the topic: - Tested on clusters with N nodes (10? 50? 3?) <- I'd start at proposing min maybe 25 - Tested on data set sizes >= TB (Maybe 30 given the 25 node count w/current density) - Soak tested in aggressively adversarial scenarios w/proven correctness for 72 hours (fallout w/nodes down, up, bounce, GC pausing, major compaction, major repair, packet loss, bootstrapping, etc. We could come up with a list) - Some form of the above in mixed-version clusters - Minimum 75% code coverage on non-boilerplate code - Where possible (i.e. not a brand new semantic / feature), diff-tested against existing schemas making use of APIs in mixed version clusters as well as on new-version only clusters (in case of refactor / internal black box rewrite) Some discrete bars like the above for a definition of done may make sense. Any other ideas to add or differing points of view on what the #'s above should be? Or disagreement on the items in the list above? I hold all the above loosely, so don't hesitate to respond, disagree, or totally shoot down. Or propose an entirely different approach to determining a Definition of Done we could engage with. Last but not least, we'd have to make infrastructure like this available to the project at large for usage and validation on testing features or this exercise will simply serve to deter engagement with the project outside a small subset of the population with resources to dedicate to this type of testing which I think we don't want. On Wed, Jul 15, 2020 at 11:53 AM Benedict Elliott Smith wrote: > Perhaps you could clarify what you personally hope we _should_ agree as a > project, and what you want us to _not_ agree (blossom in infinite variety)? > > My view: We need to agree a shared framework for quality going forwards. > This will raise the bar to contributions, including above many that already > exist. So, we then need a roadmap to meeting the framework's requirements > for past and future contributions, so that feature development does not > suffer too greatly from the extra expectations imposed upon them. I hope > the framework and roadmap will be very specific and prescriptive in setting > their minimum standards, which can of course be further augmented as any > contributor desires. > > This seems to be the only way to come to an agreement about the point of > contention you raise: some people perceive an insufficient concern about > quality, others perceive a surplus of concern about quality. Until we > agree quite specifically what we mean, this tension will persist. I also > think it's a great way to improve project efficiency, if a contributor so > cares: resources can be focused on the shared requirements first, since > they're the "table stakes". > > Could you elaborate what you would prefer to leave out of this in your > "Definition of Done"? > > > On 15/07/2020, 16:28, "Joshua McKenzie" wrote: > > > > > This section reads as very anti-adding tests to test/unit; I am 100% > in > > favor of improving/creating our smoke, integration, regression, > > performance, E2E, etc. testing, but don't think I am as negative to > > test/unit, these tests are still valuable and more are welcome. > > I am a strong proponent of unit tests; upon re-reading the document I > don't > draw the same conclusion you do about the implications of the > verbiage, however it's completely reasonable to have a point of view > that's > skeptical of people on this project's dedication to rigor and quality. > :) I > think it's critical to "name and tame" the current architectural > constraints that undermine our ability to thoroughly unit test, as > well as > understand and mitigate the weaknesses of our current unit testing > capabilities. A discrete example - attempting to "unit test" anything > in > the CommitLog largely leads to the entire CommitLog package spinning > up, > which drags in other packages, and before you know it you have multiple > modules up and running thanks to the dependency tree. This is something > myself, Jason, Stupp, Branimir, and others have all repeatedly burned > time > on trying to delicately walk through re: test spin up and tear down. > This > has ramifications far beyond just the time lost by e
[DISCUSS] Updating the companies listed on the home page as C* users
While creating a third-party page (CASSANDRA-15940), I decided to check the links in the Proven block on the home page: [image: Screen Shot 2020-07-15 at 12.44.30.png] Turns out, a lot of those links are dead planetcassandra links. And some of those companies are now using other software, like Scylla. If anyone can offer current links that show company usage, I'd appreciate it. I've found these: For two of these, I found talks in the last 2 years at DataStax events, but I didn't find more general links. Feel free to point me to different resources. Thanks, Lorina Lorina Poland e. lor...@datastax.com w. www.datastax.com
Cassandra Kubernetes SIG meeting tomorrow
Hi everyone, Just a reminder that our SIG will be meeting tomorrow at 11AM PST. We have Zain Malik from the Kudo project coming to talk to us about operator builder that has just just entered the sandbox at the CNCF. John Sanda will not be able to make it this week but will forward dome notes on the community CRD for discussion. https://cwiki.apache.org/confluence/display/CASSANDRA/2020-07-16+Cassandra+Kubernetes+Operator+SIG See you there, Patrick
Re: Cassandra Kubernetes SIG meeting tomorrow
Unfortunately I have a conflict and won't be able to attend. While I won't be there, I want to suggest some topics in an effort to get us closer to a code drop: 1. operator framework - operator-sdk vs kubebuilder vs kudo (vs something else) 2. build tool(s) 3. CI 4. e2e test framework, libraries, etc. I think most of the C* operator projects are built with operator-sdk. It would be nice to hear any thoughts on kubebuilder. It is perfect timing for Zain to talk about the Kudo project as well. I think it is safe to say that Make is the de facto build tool for Go projects in general. Cass Operator uses https://magefile.org/. I am not sure if CI needs to be sorted out now, but I think it makes sense to at least get the conversation started. Lastly, it would be great to get people's thoughts on test frameworks, libraries, etc. operator-sdk for example provides a test framework which provides options for running tests both out of cluster as well as in cluster. Cass Operator uses https://onsi.github.io/ginkgo/ and kubectl for integration tests out of cluster. CassKop uses https://github.com/aelsabbahy/goss/tree/master/extras/dgoss for image testing/validation. Thanks John On Wed, Jul 15, 2020 at 8:53 PM Patrick McFadin wrote: > Hi everyone, > > Just a reminder that our SIG will be meeting tomorrow at 11AM PST. We have > Zain Malik from the Kudo project coming to talk to us about operator > builder that has just just entered the sandbox at the CNCF. > > John Sanda will not be able to make it this week but will forward dome > notes on the community CRD for discussion. > > > https://cwiki.apache.org/confluence/display/CASSANDRA/2020-07-16+Cassandra+Kubernetes+Operator+SIG > > See you there, > > Patrick > -- - John
