+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
