+0
I built and ran tests in DEBUG configuration (fast mode) on macOS
X 10.13.6. Some of them failed. The majority of failures are due to
kerberos-related issues in HMS-related tests:
18 - client-test.6 (Failed)
131 - master_failover-itest.0 (Failed)
132 - master_failover-itest.1 (Failed)
133 - master_failover-itest.2 (Failed)
138 - master_sentry-itest.0 (Failed)
139 - master_sentry-itest.1 (Failed)
140 - master_sentry-itest.2 (Failed)
141 - master_sentry-itest.3 (Failed)
142 - master_sentry-itest.4 (Failed)
143 - master_sentry-itest.5 (Failed)
144 - master_sentry-itest.6 (Failed)
145 - master_sentry-itest.7 (Failed)
199 - sentry_authz_provider-test.0 (Failed)
200 - sentry_authz_provider-test.1 (Failed)
201 - sentry_authz_provider-test.2 (Failed)
202 - sentry_authz_provider-test.3 (Failed)
203 - sentry_authz_provider-test.4 (Failed)
204 - sentry_authz_provider-test.5 (Failed)
205 - sentry_authz_provider-test.6 (Failed)
206 - sentry_authz_provider-test.7 (Failed)
233 - sentry_client-test (Failed)
236 - webserver-test (Failed)
298 - kudu-tool-test.3 (Failed)
313 - tablet_server-test (Failed)
391 - trace-test (Failed)
I think it should not block the release given macOS is a development-only
platform for Kudu.
I also built the code tagged 1.11.0-RC3 at CentOS6.6. I played with the
'live_row_count' metric. I found that both 'masterWebServerURL:/metrics'
and 'kudu table statistics' report live row count correspondingly if
running new binaries with old data. However:
1. Running 1.11.0 master with 1.10.0 tablet servers report 0 at
'masterWebServerURL:/metrics' and in the output of 'kudu tablet statistics'.
2. Running 1.11.0 kudu CLI tool against 1.10.0 cluster reports an error:
'Remote error: failed to get table statistics.: Invalid argument: Call on
service kudu.master.MasterService received at a.b.c.d:x from a.b.c.d:y with
an invalid method name: GetTableStatistics'
3. Running 1.11.0 master and some 1.11.0 tablet servers, and the rest
1.10.0 tablet servers returns inconsistent results for the 'live_row_count'
and on_disk_size metrics. For example:
TABLE default.loadgen_auto_1fe440bbeb25446fb6f98bd9e0aa473a
on disk size: 42139829
live row count: 1246
When running all tablet servers with 1.11.0 version the results were
TABLE default.loadgen_auto_1fe440bbeb25446fb6f98bd9e0aa473a
on disk size: 67423947
live row count: 2000
I don't think anything of that is a no-go for the release, though. I think
we can document the issues with the newly introduced metrics in the release
notes and fix them in the future 1.12 release.
Thanks,
Alexey
On Mon, Oct 28, 2019 at 6:43 PM Andrew Wong <[email protected]>
wrote:
> +1
>
> I deployed this in RELEASE mode on a Centos 6.6 cluster that had many
> pre-1.11 tables. I added a range partition (using the new CLI tool) to one
> such pre-1.11 table and added some rows. The web UI reported a live row
> count of N/A for the table, even though I could see the live row count for
> the new range tablet was non-zero.
>
> I did see that running the `kudu table statistics` tool printed out a live
> row count of 0 for this table, rather than "N/A" as in the web UI. Looking
> through the code, we could maybe add a `has_live_row_count()` API to
> KuduTableStatistics or something to that effect and print a more obviously
> invalid result. I think that doesn't have to be done in this release.
>
> I also played around with maintenance mode, stats reporting, dropping
> ranges via CLI, the metrics aggregation in the web UI, verifying
> correctness mostly visually.
>
> On Mon, Oct 28, 2019 at 4:43 PM Hao Hao <[email protected]>
> wrote:
>
> > +1 built at DEBUG mode and ran on CentOS 7.3, all the tests passed.
> >
> > Best,
> > Hao
> >
> > On Mon, Oct 28, 2019 at 4:36 PM Grant Henke <[email protected]
> >
> > wrote:
> >
> > > +1 I ran the build locally on my Mac along with a full Xenial Docker
> > build.
> > >
> > > On Mon, Oct 28, 2019 at 10:45 AM Adar Lieber-Dembo
> > > <[email protected]> wrote:
> > >
> > > > +1
> > > >
> > > > I ran all tests in slow DEBUG mode on CentOS 6.6 and Ubuntu 18.04.
> All
> > > > of them passed.
> > > >
> > > > I'm surprised that live row count still has issues given the late
> > > > breaking fixes that Yingchun Lai merged into 1.11.0. His last fix was
> > > > expressly intended to address the problem where a table with a mix of
> > > > legacy and new tablets misreports the count: it should report a live
> > > > row count of 0. Zhang Yifan, could you file a JIRA with your
> findings?
> > > >
> > > > On Sun, Oct 27, 2019 at 4:06 PM Greg Solovyev
> > > > <[email protected]> wrote:
> > > > >
> > > > > +1
> > > > > I ran dev docker build per
> > > > > https://github.com/apache/kudu/tree/1.11.0-RC3/docker - no errors.
> > > > > Greg
> > > > >
> > > > >
> > > > > On Fri, Oct 25, 2019 at 5:27 AM Attila Bukor <[email protected]>
> > > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > - Successfully built in RELEASE mode on macOS Mojave and CentOS
> > 7.3.
> > > > > >
> > > > > > - Ran tests in slow mode on CentOS, memory_gc-itest seems to be
> > flaky
> > > > as it
> > > > > > failed at first but I re-ran it several times and it passed.
> > There
> > > > was
> > > > > > another
> > > > > > failure which was environmental (address already in use).
> > > > > >
> > > > > > - Built and tested the Java clients, there was one environmental
> > > > failure
> > > > > > (too
> > > > > > many open files).
> > > > > >
> > > > > > - Successfully built examples/java/insert-loadgen and
> > > > > > examples/scala/spark-example using the 1.11.0 convenience JARs
> > from
> > > > the
> > > > > > staging repo.
> > > > > >
> > > > > > Attila
> > > > > >
> > > > > > On Fri, Oct 25, 2019 at 07:34:45PM +0800,
> > [email protected]
> > > > wrote:
> > > > > > > Hi Yifan,
> > > > > > >
> > > > > > > Thanks for your report, but I guess that's a known problem. In
> > the
> > > > > > previous
> > > > > > > patch submitted by Yingchun, it has improved the output of the
> > > > defective
> > > > > > > value, especially for the historical range partitioned tables.
> At
> > > the
> > > > > > same
> > > > > > > time, the problems you found in the master's metrics and kudu
> CLI
> > > > tool
> > > > > > are
> > > > > > > real. But both of them have a lower priority in my opinion, and
> > > > shouldn't
> > > > > > > block the release. As your said we can fix them in the next
> > > version.
> > > > > > >
> > > > > > > +1
> > > > > > > Ran both debug and release mode on debian8.9, all c++ tests
> > passed
> > > > except
> > > > > > > client_symbol-test as I made a soft link on directory "bin".
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 何李夫
> > > > > > > 2019-10-25 19:34:19
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > -----邮件原件-----
> > > > > > > 发件人: [email protected]
> > > > > > > <[email protected]> 代表
> > > Zhang
> > > > > > Yifan
> > > > > > > 发送时间: 2019年10月25日 15:08
> > > > > > > 收件人: [email protected]; [email protected]
> > > > > > > 主题: Re:[VOTE] Apache Kudu 1.11.0-RC3
> > > > > > >
> > > > > > > +0Built on CentOS 7.3. Ran DEBUG tests in slow mode. No
> > failures.It
> > > > seems
> > > > > > > the table metric 'live_row_count' still has some problems.
> > > > > > >
> > > > > > >
> > > > > > > When master aggregate all tablets' live_row_count, the table
> > metric
> > > > > > > 'live_row_count' is 0 for legacy tables, and for legacy tables
> > with
> > > > newly
> > > > > > > added partitions, the value is live row count of new
> partitions.
> > I
> > > > could
> > > > > > get
> > > > > > > the metric value via master’s Web UI at master:8051/metrics.
> > > > > > > I also tried to get this metric via `kudu table statistics` CLI
> > > > tool, the
> > > > > > > value is 0 for both legacy tables and partly legacy tables.
> > > > > > > I think this new table metric should be invalid if the table
> > > contains
> > > > > > some
> > > > > > > legacy tablets, and we can't get the metric via clients and Web
> > UI.
> > > > > > >
> > > > > > >
> > > > > > > We should at least document the meaning of the table metric in
> > the
> > > > > > release
> > > > > > > notes and fix it in 1.12.0.
> > > > > > >
> > > > > > >
> > > > > > > At 2019-10-24 08:50:28, "Alexey Serbin"
> > > <[email protected]
> > > > >
> > > > > > > wrote: >Hello Kudu devs! > >The Apache Kudu team is happy to
> > > > announce the
> > > > > > > third release candidate (RC3) >for Apache Kudu 1.11.0. >
> >Apache
> > > Kudu
> > > > > > 1.11.0
> > > > > > > is a minor release that offers many improvements and >fixes
> > >since
> > > > the
> > > > > > prior
> > > > > > > release. > >This is a source-only release. The artifacts have
> > been
> > > > staged
> > > > > > > here: >
> https://dist.apache.org/repos/dist/dev/kudu/1.11.0-RC3/
> > >
> > > > >Java
> > > > > > > convenience binaries in the form of a Maven repository are
> staged
> > > > here: >
> > > > > > >
> > > >
> https://repository.apache.org/content/repositories/orgapachekudu-1041
> > >
> > > > > > >It
> > > > > > > is tagged in Git as 1.11.0-RC3 and the corresponding hash is
> the
> > > > > > >following:
> > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=kudu.git;a=commit;h=08db97c591d9131cb
> > > > > > > ef9b8e5b4f44a6e854c25f0 > >The release notes can be found
> here: >
> > > > > > >
> > > > > >
> > > >
> > >
> >
> https://github.com/apache/kudu/blob/branch-1.11.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 > >I'd
> > > suggest
> > > > > > going
> > > > > > > through the README and the release notes, building Kudu, >and
> > > > >running
> > > > > > the
> > > > > > > unit tests. Testing out the Maven repo would also be
> > >appreciated.
> > > > > > >Another
> > > > > > > test is to check for the behavior of the newly introduced
> > >table's
> > > > live
> > > > > > rows
> > > > > > > metric when upgrading from Kudu 1.10 with already existing
> > >tables,
> > > > > > making
> > > > > > > sure it behaves the expected way for the legacy tables and
> >also
> > > for
> > > > > > legacy
> > > > > > > tables with newly added partitions while running Kudu 1.11. >
> > >The
> > > > vote
> > > > > > will
> > > > > > > run until Mon Oct 28 11:00:00 PDT 2019. This is more than
> >usual
> > 72
> > > > hours
> > > > > > > from the time of sending out this e-mail message because >of
> the
> > > > > > weekend. >
> > > > > > > > >Thanks, >Alexey
> > > > > > >
> > > > > >
> > > >
> > >
> > >
> > > --
> > > Grant Henke
> > > Software Engineer | Cloudera
> > > [email protected] | twitter.com/gchenke | linkedin.com/in/granthenke
> > >
> >
>
>
> --
> Andrew Wong
>
