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 <[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 > > > > > > > >
