+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 <aw...@apache.org> 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 <aser...@cloudera.com.invalid
> >
> 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 <ban...@apache.org>
> wrote:
> >
> > > Gentle reminder for voting on 1.15.0 RC2.
> > >
> > > -Bankim
> > >
> > > On Thu, Jun 10, 2021 at 3:16 PM Bankim Bhavsar <ban...@apache.org>
> > 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
> > > >
> > >
> >
>

Reply via email to