Sure. Let me know if you need help with Druid adapter. On Mon, Mar 18, 2019 at 5:36 PM Kevin Risden <[email protected]> wrote:
> Rebuilding the VM for just druid found that there is an issue with > zookeeper version - 3.4.10 doesn't exist on the release mirrors anymore for > when installing druid. Fixing to point to 3.4.13 and see if that will let > me build the test vm correctly. > > Kevin Risden > > > On Mon, Mar 18, 2019 at 5:32 PM Kevin Risden <[email protected]> wrote: > > > Andrei - Thanks I just checked the results and see the same thing for > > MongoDB. I see you opened CALCITE-2931 as well with a PR. Since this is > > test only don't think this blocks the 1.19.0 release. > > > > As for Druid, looks like I'm still getting connection reset errors after > > rebuilding the test dataset vm. I'm going to try to rebuild the VM with > > just Druid to see if its a memory issue. > > > > Kevin Risden > > > > > > On Mon, Mar 18, 2019 at 4:54 PM Andrei Sereda <[email protected]> wrote: > > > >> I just run Mongo tests using docker image. > >> > >> Failures seem to be related to key order in Bson document. Example: > >> > >> Expected > >> {$project: {POP: '$pop', STATE: '$state'}} > >> > >> Actual > >> {$project: {STATE: '$state', POP: '$pop'}} > >> > >> Those queries don't run as part of unit tests because they only work in > >> mongo (not fongo). > >> > >> I will address those inconsistencies > >> (MongoAdapterTest#testGroupByAvgSumCount and > >> MongoAdapterTest#testDistinctCountOrderBy) > >> > >> On Mon, Mar 18, 2019 at 2:05 PM > >> Kevin Risden > >> <[email protected]> wrote: > >> > >> > For the calcite-test-dataset vm, the docs say you can halt/up the VM. > It > >> > turns out that Druid doesn't restart on up and MongoDB fails to start > >> due > >> > to /var/run/mongodb missing. /var/run is symlinked to /run and /run is > >> > mounted as tmpfs so the folders are cleared on a restart. > >> > > >> > I don't know if this is what is causing the failures you saw but it > was > >> > causing issues with the "timeout" issues I saw. I am rebuilding the VM > >> and > >> > checking the Druid / MongoDB integration tests individually. > >> > > >> > Kevin Risden > >> > > >> > > >> > On Mon, Mar 18, 2019 at 1:43 PM Kevin Risden <[email protected]> > >> wrote: > >> > > >> > > Stamatis - Can you open JIRA cases for the Druid and MongoDB > >> integration > >> > > test failures with details? > >> > > > >> > > It would be good to track them down not sure if they would block the > >> > > release depending on the errors. I seem to have an issue with my > >> > > calcite-test-dataset vm currently since getting timeout errors for > >> Mongo > >> > > and Druid. I'll see if I can track them down but would be good to > see > >> > what > >> > > the failure details are. > >> > > > >> > > I did not see the MySQL test failure. I could have missed the > >> > > Druid/MongoDB integration test failures since the integration test > run > >> > > stopped at Postgres. > >> > > > >> > > Kevin Risden > >> > > > >> > > > >> > > On Mon, Mar 18, 2019 at 12:09 PM Stamatis Zampetakis < > >> [email protected]> > >> > > wrote: > >> > > > >> > >> System A: MacOS 10.13.6, jdk9, maven 3.5.2 > >> > >> System B: Ubuntu 18.04LTS, jdk1.8.0_192, maven 3.5.3 > >> > >> > >> > >> -run unit tests (mvn clean install) on staged sources and git repo > OK > >> > >> -checked signatures and checksums OK > >> > >> -went quickly over release note OK > >> > >> -run integration tests (mvn -Dtest=foo -DfailIfNoTests=false -Pit > >> verify > >> > >> -fn) KO > >> > >> A brief summary of the errors is given below: > >> > >> [ERROR] Tests run: 290, Failures: 1, Errors: 0, Skipped: 21, Time > >> > elapsed: > >> > >> 23.703 s <<< FAILURE! - in org.apache.calcite.test.JdbcTest (MySQL) > >> > >> [ERROR] Tests run: 290, Failures: 0, Errors: 1, Skipped: 21, Time > >> > elapsed: > >> > >> 34.468 s <<< FAILURE! - in org.apache.calcite.test.JdbcTest > >> (Postgres) > >> > >> [ERROR] Tests run: 36, Failures: 1, Errors: 0, Skipped: 0, Time > >> elapsed: > >> > >> 1.478 s <<< FAILURE! - in org.apache.calcite.test.JdbcAdapterTest > >> > >> (Postgres) > >> > >> [ERROR] Tests run: 234, Failures: 16, Errors: 6, Skipped: 0, Time > >> > elapsed: > >> > >> 52.406 s <<< FAILURE! - in org.apache.calcite.test.DruidAdapterIT > >> > (Druid) > >> > >> [ERROR] Tests run: 31, Failures: 2, Errors: 0, Skipped: 6, Time > >> elapsed: > >> > >> 3.236 s <<< FAILURE! - in org.apache.calcite.test.MongoAdapterIT > >> > (MongoDB) > >> > >> -run tests on downstream project KO > >> > >> The errors occur due to the simplification of a filter =($0, false) > >> to > >> > >> NOT($0) ($0 is boolean). The transformation is valid so in > principle > >> the > >> > >> tests should not fail. However it makes me wonder if adding > negation > >> is > >> > >> really a simplification. If I want to push this expression into an > >> > index > >> > >> (e.g., B+Tree) I would have to rewrite it again to something > >> equivalent > >> > to > >> > >> =($0, false) since many types of indexes do not support negative > >> > >> conditions. > >> > >> > >> > >> My vote is 0 (non-binding) for two reasons: > >> > >> (i) there are integration tests failing for which we have not > >> identified > >> > >> the reason (excluding tests in Postgres) and may hide regressions; > >> > >> (ii) the simplification behavior described above may cause problems > >> in > >> > >> certain use-cases. > >> > >> > >> > >> Στις Παρ, 15 Μαρ 2019 στις 9:45 μ.μ., ο/η Michael Mior < > >> > [email protected]> > >> > >> έγραψε: > >> > >> > >> > >> > +1 (binding) checked hashes and signature, compiled and ran tests > >> and > >> > >> > a RAT check. > >> > >> > -- > >> > >> > Michael Mior > >> > >> > [email protected] > >> > >> > > >> > >> > Le ven. 15 mars 2019 à 10:38, > >> > >> Kevin Risden > >> > >> <[email protected]> a écrit : > >> > >> > > > >> > >> > > Hi all, > >> > >> > > > >> > >> > > I have created a build for Apache Calcite 1.19.0, release > >> candidate > >> > 1. > >> > >> > > > >> > >> > > Thanks to everyone who has contributed to this release. > >> > >> > > > >> > >> > > Since RC 0, we have fixed the following issues: > >> > >> > > * [CALCITE-2925] Exclude maven-wrapper.jar from source > >> distribution > >> > >> > > > >> > >> > > You can read the release notes here: > >> > >> > > > >> > >> > >> > > >> > https://github.com/apache/calcite/blob/branch-1.19/site/_docs/history.md > >> > >> > > > >> > >> > > The commit to be voted upon: > >> > >> > > > >> > >> > > >> > >> > >> > > >> > https://gitbox.apache.org/repos/asf?p=calcite.git;a=commit;h=ad11340e5c5abddaa6f2729c9faa2043c4643a8d > >> > >> > > > >> > >> > > Its hash is ad11340e5c5abddaa6f2729c9faa2043c4643a8d. > >> > >> > > > >> > >> > > The artifacts to be voted on are located here: > >> > >> > > > >> > >> > > >> > >> > >> > > >> > https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.19.0-rc1/ > >> > >> > > > >> > >> > > The hashes of the artifacts are as follows: > >> > >> > > src.tar.gz.sha256 > >> > >> > > > 8dbe7e81d955019d78e7de270089fb42726c827f719bfd5a5d11f734fac7face > >> > >> > > > >> > >> > > A staged Maven repository is available for review at: > >> > >> > > > >> > >> > > >> > >> > >> > > >> > https://repository.apache.org/content/repositories/orgapachecalcite-1055/ > >> > >> > > > >> > >> > > Release artifacts are signed with the following key: > >> > >> > > https://people.apache.org/keys/committer/krisden.asc > >> > >> > > > >> > >> > > Please vote on releasing this package as Apache Calcite 1.19.0. > >> > >> > > > >> > >> > > The vote is open for the next 96 hours (due to the weekend) and > >> > passes > >> > >> > if a > >> > >> > > majority of > >> > >> > > at least three +1 PMC votes are cast. > >> > >> > > > >> > >> > > [ ] +1 Release this package as Apache Calcite 1.19.0 > >> > >> > > [ ] 0 I don't feel strongly about it, but I'm okay with the > >> release > >> > >> > > [ ] -1 Do not release this package because... > >> > >> > > > >> > >> > > Here is my vote: > >> > >> > > +1 (binding) > >> > >> > > > >> > >> > > Kevin Risden > >> > >> > > >> > >> > >> > > > >> > > >> > > >
