The vote is now closed. It passes with 3 binding +1s, 1 non-binding +1, and no -1s of any kind.
I will work on the release steps next and send out the announcement after the site and mirrors are updated. Thanks, -Bankim. On Fri, Jun 18, 2021 at 12:40 PM Grant Henke <[email protected]> wrote: > +1 > Successfully built and ran C++ tests on macOS 10.15.7 in release and debug. > I build all of the various docker OS images. > I tested the MacOS binary jar using the java examples. > > > > > On Thu, Jun 17, 2021 at 2:44 PM Mahesh Reddy <[email protected]> > wrote: > >> +1 >> Successfully built and ran C++ tests on macOS 10.15.7 in debug >> configuration. The following C++ tests failed: >> >> 149 - master_authz-itest.0 (Failed) >> >> 150 - master_authz-itest.1 (Failed) >> >> 151 - master_authz-itest.2 (Failed) >> >> 152 - master_authz-itest.3 (Failed) >> >> 153 - master_authz-itest.4 (Failed) >> >> 154 - master_authz-itest.5 (Failed) >> >> 155 - master_authz-itest.6 (Failed) >> >> 156 - master_authz-itest.7 (Failed) >> >> 174 - raft_consensus_nonvoter-itest (Failed) >> >> 186 - security-itest (Failed) >> >> 240 - mini_ranger-test (Failed) >> >> 241 - ranger_client-test (Failed) >> >> 336 - kudu-tool-test.0 (Failed) >> >> 338 - kudu-tool-test.2 (Failed) >> >> 339 - kudu-tool-test.3 (Failed) >> >> 439 - trace-test (Failed) >> >> Given that macOS is a developer platform and not all tests are expected to >> pass on it, I decided to go ahead and give it a +1. >> On top of that, I've seen many of these test failures in the past so I >> don't think it's cause for concern. >> >> On Wed, Jun 16, 2021 at 1:00 AM Andrew Wong <[email protected]> wrote: >> >> > +1 >> > >> > I ran all C++ tests on CentOS 7.3 in debug mode and all passed except >> those >> > involving the HMS, whose failures seem specific to my environment. >> > >> > I also deployed release binaries on a small CentOS 7.5 cluster and >> > performed >> > the following: >> > - Enabled transactions, started several transactional workloads >> committing >> > some >> > and aborting some via loadgen, and ran some transactions-related >> tooling >> > (show, list) to confirm the expected transactional states. >> > - Added a new master to the cluster using the new master-adding tooling, >> > verifying the new master could become a leader, and contained all >> tables >> > known to the previous single master. My orchestration tool of choice >> > (Cloudera Manager) was also able to manage the new master just fine >> after >> > adding a new role. >> > - Removed the existing master from the cluster using the new tooling. >> > - Altered a table comment using a custom tool that uses the C++ client. >> I >> > verified this comment was changed in the HMS and visible in Impala. >> > - Enabled table size limits, set size limits for a single table via >> > tooling, >> > and verified that further ingest attempts failed. I also verified the >> > limits >> > were visible through the newly introduced tooling. >> > >> > On Tue, Jun 15, 2021 at 9:46 PM Alexey Serbin >> <[email protected] >> > > >> > wrote: >> > >> > > +1 >> > > >> > > I built a DEBUG version of 1.15.0 RC2 from sources on Ubuntu 18.04 and >> > > CentOS 8.2 and ran tests for the backend components using ctest. >> > > >> > > Ubuntu 18.04: all passed except for: >> > > master_authz-itest: >> > > >> > > >> > >> AuthzProvidersWithOwner/MasterAuthzOwnerITest.TestMismatchedTable/Ranger_owner >> > > >> > > CentOS 8.2: all passed except for: >> > > master_hms-itest: MasterHmsTest.TestAlterTableOwner, etc. >> > > kudu-tool-test: ToolTest.TestHmsIgnoresDifferentMasters (the issue >> was >> > > due to RSA 768bit key -- I'll need to update Ranger's JVM settings to >> > allow >> > > for less secure cipher/algorithm constraints). >> > > >> > > Those Ranger-related tests in master_authz-itest are known to be a bit >> > > flaky, it's not a big deal: >> > > >> > > >> > >> http://dist-test.cloudera.org:8080/test_drilldown?test_name=master_authz-itest >> > > >> > > The root case of test failures of the scenarios from master_hms-itest >> and >> > > from kudu-tool-test at CentOS 8.2 is using 768bit RSA key for Kudu >> IPKI >> > CA >> > > in tests -- I'll need to update Ranger's JVM settings to allow for >> less >> > > secure cipher/algorithm constraints. It's a test-only failure >> related to >> > > tighter security settings on contemporary Linux distros, and so not a >> big >> > > deal. The funny fact is that not a single run for my RC verification >> > went >> > > without failing at least one of HMS scenarios since HMS tests had been >> > > introduced, and I see a similar pattern for this RC :) >> > > >> > > ToolTest.TestHmsIgnoresDifferentMasters failed because of using 768bit >> > RSA >> > > key for Kudu IPKI CA in tests -- I'll need to update Ranger's JVM >> > settings >> > > to allow for less secure cipher/algorithm constraints. It's a >> test-only >> > > failure related to tighter security settings on contemporary Linux >> > distros, >> > > and so not a big deal. >> > > >> > > Overall, those test failures are related to test-only defects and >> known >> > > flaky tests, so overall this RC is good to go, IMO. >> > > >> > > >> > > /Alexey >> > > >> > > On Tue, Jun 15, 2021 at 8:33 PM Bankim Bhavsar <[email protected]> >> > wrote: >> > > >> > > > Gentle reminder for voting on 1.15.0 RC2. >> > > > >> > > > -Bankim >> > > > >> > > > On Thu, Jun 10, 2021 at 3:16 PM Bankim Bhavsar <[email protected]> >> > > wrote: >> > > > >> > > > > Hello Kudu devs! >> > > > > >> > > > > The Apache Kudu team is happy to announce the second release >> > candidate >> > > > for >> > > > > Apache Kudu 1.15.0. >> > > > > >> > > > > Apache Kudu 1.15.0 is a minor release that offers many >> improvements >> > and >> > > > > fixes since Apache Kudu 1.14.0. >> > > > > >> > > > > This is a source-only release. The artifacts have been staged >> here: >> > > > > https://dist.apache.org/repos/dist/dev/kudu/1.15.0-RC2/ >> > > > > >> > > > > Branch: branch-1.15.x >> > > > > >> > > > > Java convenience binaries in the form of a Maven repository are >> > staged >> > > > > here: >> > > > > >> > https://repository.apache.org/content/repositories/orgapachekudu-1092/ >> > > > > >> > > > > Linux test-only Kudu binary JAR artifacts are staged here: >> > > > > >> > https://repository.apache.org/content/repositories/orgapachekudu-1093/ >> > > > > >> > > > > MacOS test-only Kudu binary JAR artifacts are staged here: >> > > > > >> > https://repository.apache.org/content/repositories/orgapachekudu-1094/ >> > > > > >> > > > > It is tagged in Git as 1.15.0-RC2 and the corresponding hash is >> the >> > > > > following: >> > > > > >> > > > > >> > > > >> > > >> > >> https://gitbox.apache.org/repos/asf?p=kudu.git;a=commit;h=64619147e7932518bb88b3f3f719d9c27cfdae68 >> > > > > >> > > > > The Release Notes notes can be found here: >> > > > > >> > > > >> > > >> > >> https://github.com/apache/kudu/blob/branch-1.15.x/docs/release_notes.adoc >> > > > > >> > > > > The KEYS file to verify the artifact signatures can be found here: >> > > > > https://dist.apache.org/repos/dist/release/kudu/KEYS >> > > > > >> > > > > Some common release validations include building Kudu, and running >> > the >> > > > unit >> > > > > tests on your platforms and environments. Additionally it is worth >> > > > running >> > > > > Kudu Java tests against kudu-binary JAR artifact using >> > > > > `-PuseBinJar=<version>` >> > > > > as described in the commit message here: >> > > > > >> > > > > >> > > > > >> > > > >> > > >> > >> https://gitbox.apache.org/repos/asf?p=kudu.git;a=commit;h=8a6faaa93f3e206ac75e8087731daccaf7ab646a >> > > > > >> > > > > The vote will run until a majority[1] is achieved, but at least >> until >> > > > > Tuesday >> > > > > June 15th 2021, to give everyone a chance to review this release >> > > > candidate >> > > > > and >> > > > > vote. >> > > > > >> > > > > Thank You, >> > > > > Bankim. >> > > > > >> > > > > [1] https://www.apache.org/foundation/voting.html#ReleaseVotes >> > > > > >> > > > >> > > >> > >> > > > -- > Grant Henke > Software Engineer | Cloudera > [email protected] | twitter.com/gchenke | linkedin.com/in/granthenke >
