Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 9D5BC200BB9 for ; Mon, 7 Nov 2016 23:50:31 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 9BF0F160AEC; Mon, 7 Nov 2016 22:50:31 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id E4DD0160AE0 for ; Mon, 7 Nov 2016 23:50:30 +0100 (CET) Received: (qmail 85438 invoked by uid 500); 7 Nov 2016 22:50:29 -0000 Mailing-List: contact reviews-help@impala.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list reviews@impala.incubator.apache.org Received: (qmail 84823 invoked by uid 99); 7 Nov 2016 22:50:29 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Nov 2016 22:50:29 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 6442E1A9A14 for ; Mon, 7 Nov 2016 22:50:28 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.362 X-Spam-Level: X-Spam-Status: No, score=0.362 tagged_above=-999 required=6.31 tests=[RDNS_DYNAMIC=0.363, SPF_PASS=-0.001] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id X8VRcx45x9Eo for ; Mon, 7 Nov 2016 22:50:26 +0000 (UTC) Received: from ip-10-146-233-104.ec2.internal (ec2-75-101-130-251.compute-1.amazonaws.com [75.101.130.251]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 752815FE24 for ; Mon, 7 Nov 2016 22:50:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by ip-10-146-233-104.ec2.internal (8.14.4/8.14.4) with ESMTP id uA7MoOeB023318; Mon, 7 Nov 2016 22:50:24 GMT Message-Id: <201611072250.uA7MoOeB023318@ip-10-146-233-104.ec2.internal> Date: Mon, 7 Nov 2016 22:50:24 +0000 From: "David Knupp (Code Review)" To: Martin Grund , impala-cr@cloudera.com, reviews@impala.incubator.apache.org CC: Harrison Sheinblatt , Michael Brown , Taras Bobrovytsky Reply-To: dknupp@cloudera.com X-Gerrit-MessageType: comment Subject: =?UTF-8?Q?=5BImpala-ASF-CR=5D_IMPALA-4365=3A_Enabling_end-to-end_tests_on_a_remote_cluster=0A?= X-Gerrit-Change-Id: I1f443a1728a1d28168090c6f54e82dec2cb073e9 X-Gerrit-ChangeURL: X-Gerrit-Commit: 1254351333c390e95ddbfa3783577d3b67970927 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-Disposition: inline User-Agent: Gerrit/2.12.2 archived-at: Mon, 07 Nov 2016 22:50:31 -0000 David Knupp has posted comments on this change. Change subject: IMPALA-4365: Enabling end-to-end tests on a remote cluster ...................................................................... Patch Set 13: (3 comments) http://gerrit.cloudera.org:8080/#/c/4769/13//COMMIT_MSG Commit Message: Line 51: still problems to work out with the remote data load script itself. > Did you try loading data on a remote cluster and running tests on in with t Yes, many times. I should update this sentence to be more clear. This is mainly a references to the several "clean up" changes that Harrison suggested earlier, for which JIRA's have been opened. We can address those when there's time. More pressing than cleaning up all those things is fact that we need to have this checked in order to validate Impala running against a remote CDH 5.10 cluster, and time is getting short. We have less than two weeks now. There were some other actual problems that were mysterious to me initially. E.g., Kudu related failures started appearing once recent Kudu changes were submitted -- until I realized that this issue was breaking things: https://jira.cloudera.com/browse/OPSAPS-37322 But after tweaking the cluster, data loading works, and tests run -- though many tests may need to be tweaked to work remotely. http://gerrit.cloudera.org:8080/#/c/4769/13/bin/remote_data_load.py File bin/remote_data_load.py: Line 534: sys.exit(1) > In general, I think it's a bad practice to call sys.exit inside functions. OK, I'll move this. I'd seen this pattern used here in other scripts here (e.g., load-data.py that we use for local data loading), so didn't know it was a frowned upon practice. http://gerrit.cloudera.org:8080/#/c/4769/13/testdata/datasets/functional/schema_constraints.csv File testdata/datasets/functional/schema_constraints.csv: PS13, Line 120: Wide tables fail due to the SERDEPROPERTIES limits > is this a new issue? Is it specific to remote data loading? For our mini-cluster, we work around this problem here: https://github.com/apache/incubator-impala/blob/master/bin/create-test-configuration.sh#L99 However, create-test-configuration.sh is part of our local build process. It doesn't get called when CDH is deployed to a remote cluster. Besides, that script assumes that the metastore database will always be postgres, which is not the case when testing against a remote cluster. Before the change to this file, I had been using another hand-rolled script to configure the property separately after deployment. With this, I can drop that step. I've also tested the local data load after this change, and it's unaffected. -- To view, visit http://gerrit.cloudera.org:8080/4769 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-MessageType: comment Gerrit-Change-Id: I1f443a1728a1d28168090c6f54e82dec2cb073e9 Gerrit-PatchSet: 13 Gerrit-Project: Impala-ASF Gerrit-Branch: master Gerrit-Owner: David Knupp Gerrit-Reviewer: David Knupp Gerrit-Reviewer: Harrison Sheinblatt Gerrit-Reviewer: Martin Grund Gerrit-Reviewer: Michael Brown Gerrit-Reviewer: Taras Bobrovytsky Gerrit-HasComments: Yes