You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kudu.apache.org by hz...@corp.netease.com on 2019/10/25 11:34:45 UTC
回复: [VOTE] Apache Kudu 1.11.0-RC3
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
-----邮件原件-----
发件人: dev-return-6342-hzhelifu=corp.netease.com@kudu.apache.org
<de...@kudu.apache.org> 代表 Zhang Yifan
发送时间: 2019年10月25日 15:08
收件人: dev@kudu.apache.org; aserbin@cloudera.com
主题: 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" <as...@cloudera.com.INVALID>
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
Re: 回复: [VOTE] Apache Kudu 1.11.0-RC3
Posted by Alexey Serbin <as...@cloudera.com.INVALID>.
+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 <aw...@cloudera.com.invalid>
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 <ha...@cloudera.com.invalid>
> 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 <ghenke@cloudera.com.invalid
> >
> > 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
> > > <ad...@cloudera.com.invalid> 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
> > > > <gs...@cloudera.com.invalid> 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 <ab...@apache.org>
> > > 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,
> > hzhelifu@corp.netease.com
> > > > 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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > -----邮件原件-----
> > > > > > > 发件人: dev-return-6342-hzhelifu=corp.netease.com@kudu.apache.org
> > > > > > > <de...@kudu.apache.org> 代表
> > > Zhang
> > > > > > Yifan
> > > > > > > 发送时间: 2019年10月25日 15:08
> > > > > > > 收件人: dev@kudu.apache.org; aserbin@cloudera.com
> > > > > > > 主题: 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"
> > > <aserbin@cloudera.com.INVALID
> > > > >
> > > > > > > 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
> > > grant@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
> > >
> >
>
>
> --
> Andrew Wong
>
Re: 回复: [VOTE] Apache Kudu 1.11.0-RC3
Posted by Andrew Wong <aw...@cloudera.com.INVALID>.
+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 <ha...@cloudera.com.invalid>
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 <gh...@cloudera.com.invalid>
> 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
> > <ad...@cloudera.com.invalid> 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
> > > <gs...@cloudera.com.invalid> 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 <ab...@apache.org>
> > 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,
> hzhelifu@corp.netease.com
> > > 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
> > > > > >
> > > > > >
> > > > > >
> > > > > > -----邮件原件-----
> > > > > > 发件人: dev-return-6342-hzhelifu=corp.netease.com@kudu.apache.org
> > > > > > <de...@kudu.apache.org> 代表
> > Zhang
> > > > > Yifan
> > > > > > 发送时间: 2019年10月25日 15:08
> > > > > > 收件人: dev@kudu.apache.org; aserbin@cloudera.com
> > > > > > 主题: 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"
> > <aserbin@cloudera.com.INVALID
> > > >
> > > > > > 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
> > grant@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
> >
>
--
Andrew Wong
Re: 回复: [VOTE] Apache Kudu 1.11.0-RC3
Posted by Hao Hao <ha...@cloudera.com.INVALID>.
+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 <gh...@cloudera.com.invalid>
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
> <ad...@cloudera.com.invalid> 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
> > <gs...@cloudera.com.invalid> 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 <ab...@apache.org>
> 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, hzhelifu@corp.netease.com
> > 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
> > > > >
> > > > >
> > > > >
> > > > > -----邮件原件-----
> > > > > 发件人: dev-return-6342-hzhelifu=corp.netease.com@kudu.apache.org
> > > > > <de...@kudu.apache.org> 代表
> Zhang
> > > > Yifan
> > > > > 发送时间: 2019年10月25日 15:08
> > > > > 收件人: dev@kudu.apache.org; aserbin@cloudera.com
> > > > > 主题: 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"
> <aserbin@cloudera.com.INVALID
> > >
> > > > > 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
> grant@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
>
Re: 回复: [VOTE] Apache Kudu 1.11.0-RC3
Posted by Grant Henke <gh...@cloudera.com.INVALID>.
+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
<ad...@cloudera.com.invalid> 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
> <gs...@cloudera.com.invalid> 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 <ab...@apache.org> 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, hzhelifu@corp.netease.com
> 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
> > > >
> > > >
> > > >
> > > > -----邮件原件-----
> > > > 发件人: dev-return-6342-hzhelifu=corp.netease.com@kudu.apache.org
> > > > <de...@kudu.apache.org> 代表 Zhang
> > > Yifan
> > > > 发送时间: 2019年10月25日 15:08
> > > > 收件人: dev@kudu.apache.org; aserbin@cloudera.com
> > > > 主题: 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" <aserbin@cloudera.com.INVALID
> >
> > > > 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
grant@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
Re: 回复: [VOTE] Apache Kudu 1.11.0-RC3
Posted by Alexey Serbin <as...@cloudera.com.INVALID>.
I'm surprised we got non-0 count for a table with a mix of legacy and new
tablets. I hope that doesn't bring any incompatibilities, so we could
address that in the future 1.12 release. It would help if we had a JIRA
with documented reproduction scenarios.
I'll update the release notes in branch-1.11.x w.r.t. the behavior of the
'live_row_count' metric. If this RC pass, the note will get into the
branch, but not into the released source tarball.
Let's extend the vote deadline till 6 pm PDT (Mon Oct 28 18:00:00 PDT 2019).
Thanks,
Alexey
On Mon, Oct 28, 2019 at 8:45 AM Adar Lieber-Dembo <ad...@cloudera.com> 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
> <gs...@cloudera.com.invalid> 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 <ab...@apache.org> 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, hzhelifu@corp.netease.com
> 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
> > > >
> > > >
> > > >
> > > > -----邮件原件-----
> > > > 发件人: dev-return-6342-hzhelifu=corp.netease.com@kudu.apache.org
> > > > <de...@kudu.apache.org> 代表 Zhang
> > > Yifan
> > > > 发送时间: 2019年10月25日 15:08
> > > > 收件人: dev@kudu.apache.org; aserbin@cloudera.com
> > > > 主题: 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" <aserbin@cloudera.com.INVALID
> >
> > > > 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
> > > >
> > >
>
Re: 回复: [VOTE] Apache Kudu 1.11.0-RC3
Posted by Adar Lieber-Dembo <ad...@cloudera.com.INVALID>.
+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
<gs...@cloudera.com.invalid> 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 <ab...@apache.org> 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, hzhelifu@corp.netease.com 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
> > >
> > >
> > >
> > > -----邮件原件-----
> > > 发件人: dev-return-6342-hzhelifu=corp.netease.com@kudu.apache.org
> > > <de...@kudu.apache.org> 代表 Zhang
> > Yifan
> > > 发送时间: 2019年10月25日 15:08
> > > 收件人: dev@kudu.apache.org; aserbin@cloudera.com
> > > 主题: 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" <as...@cloudera.com.INVALID>
> > > 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
> > >
> >
Re: 回复: [VOTE] Apache Kudu 1.11.0-RC3
Posted by Greg Solovyev <gs...@cloudera.com.INVALID>.
+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 <ab...@apache.org> 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, hzhelifu@corp.netease.com 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
> >
> >
> >
> > -----邮件原件-----
> > 发件人: dev-return-6342-hzhelifu=corp.netease.com@kudu.apache.org
> > <de...@kudu.apache.org> 代表 Zhang
> Yifan
> > 发送时间: 2019年10月25日 15:08
> > 收件人: dev@kudu.apache.org; aserbin@cloudera.com
> > 主题: 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" <as...@cloudera.com.INVALID>
> > 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
> >
>
Re: 回复: [VOTE] Apache Kudu 1.11.0-RC3
Posted by Attila Bukor <ab...@apache.org>.
+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, hzhelifu@corp.netease.com 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
>
>
>
> -----邮件原件-----
> 发件人: dev-return-6342-hzhelifu=corp.netease.com@kudu.apache.org
> <de...@kudu.apache.org> 代表 Zhang Yifan
> 发送时间: 2019年10月25日 15:08
> 收件人: dev@kudu.apache.org; aserbin@cloudera.com
> 主题: 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" <as...@cloudera.com.INVALID>
> 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
>