[
https://issues.apache.org/jira/browse/BIGTOP-1307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14007515#comment-14007515
]
Martin Bukatovic edited comment on BIGTOP-1307 at 5/23/14 6:40 PM:
-------------------------------------------------------------------
I figured out all other problems and get all TestCLI cases to pass.
The main problem was in strict sudo configuration (default in RHEL 6)
which resulted in `/tmp/testcli_TIMESTAMP` not being created.
I didn't notice this immediately because of other issues and the fact
that testcli directory was created later in the process via some test case.
Tweaking of sudo configuration is needed because when you specify a user
when creating iTest shell object, it uses sudo for the switch.
So after fixing my sudo configuration to get shell object working
(I disabled few security limitations for sudo and allowed hdfs user to
switch to hdfs user itself ..), I tried two runs to verify my testing
enviroment:
- under hdfs user, all testcases passed
- under bigtop user, there were 80 failing testcases
This shows that TestCLI tests need to be run under hdfs user anyway, so
specification of hdfs user for shell object is pointless. Moreover direct
user specification requires changes in sudo configuration, which are not
needed when user is not specified.
Based on this, I propose following path which basically removes hdfs user
from shell object initialization (see attached patch).
Combined with checks listed in BIGTOP-1321, this proposal would make it
easier for anyone reading the code and setting this up what kind of enviroment
is expected.
Edit: needless to say that such change is hcfs compatible by default :)
was (Author: mbukatov):
I figured out all other problems and get all TestCLI cases to pass.
The main problem was in strict sudo configuration (default in RHEL 6)
which resulted in `/tmp/testcli_TIMESTAMP` not being created.
I didn't notice this immediately because of other issues and the fact
that testcli directory was created later in the process via some test case.
Tweaking of sudo configuration is needed because when you specify a user
when creating iTest shell object, it uses sudo for the switch.
So after fixing my sudo configuration to get shell object working
(I disabled few security limitations for sudo and allowed hdfs user to
switch to hdfs user itself ..), I tried two runs to verify my testing
enviroment:
- under hdfs user, all testcases passed
- under bigtop user, there were 80 failing testcases
This shows that TestCLI tests need to be run under hdfs user anyway, so
specification of hdfs user for shell object is pointless. Moreover direct
user specification requires changes in sudo configuration, which are not
needed when user is not specified.
Based on this, I propose following path which basically removes hdfs user
from shell object initialization (see attached patch).
Combined with checks listed in BIGTOP-1321, this proposal would make it
easier for anyone reading the code and setting this up what kind of enviroment
is expected.
> Some TestCLI cases fail with 'No such file or directory'
> --------------------------------------------------------
>
> Key: BIGTOP-1307
> URL: https://issues.apache.org/jira/browse/BIGTOP-1307
> Project: Bigtop
> Issue Type: Bug
> Components: Tests
> Affects Versions: 0.8.0
> Environment: HDP 2.0.6
> Reporter: Martin Bukatovic
> Priority: Critical
> Labels: test
> Attachments:
> 0001-BIGTOP-1307.-Do-not-switch-user-for-shell-object.patch, filter-cases.sh,
> testcli.nosuchfile-cases.log
>
>
> I observe weird results of xml-defined test cases of TestCLI bigtop test:
> 136 test cases failed because of 'No such file or directory' error.
> To show what the problem is, see testcase #1:
> {noformat}
> 14/05/15 16:50:40 INFO cli.CLITestHelper:
> -------------------------------------------
> 14/05/15 16:50:40 INFO cli.CLITestHelper: Test ID: [1]
> 14/05/15 16:50:40 INFO cli.CLITestHelper: Test Description: [ls:
> file using absolute path]
> 14/05/15 16:50:40 INFO cli.CLITestHelper:
> 14/05/15 16:50:40 INFO cli.CLITestHelper: Test Commands: [-fs
> hdfs://dhcp-lab-203.local:8020 -touchz /tmp/testcli_1400165386646/file1]
> 14/05/15 16:50:40 INFO cli.CLITestHelper: Test Commands: [-fs
> hdfs://dhcp-lab-203.local:8020 -ls /tmp/testcli_1400165386646/file1]
> 14/05/15 16:50:40 INFO cli.CLITestHelper:
> 14/05/15 16:50:40 INFO cli.CLITestHelper: Cleanup Commands: [-fs
> hdfs://dhcp-lab-203.local:8020 -rm /tmp/testcli_1400165386646/file1]
> 14/05/15 16:50:40 INFO cli.CLITestHelper:
> 14/05/15 16:50:40 INFO cli.CLITestHelper: Comparator:
> [TokenComparator]
> 14/05/15 16:50:40 INFO cli.CLITestHelper: Comparision result:
> [fail]
> 14/05/15 16:50:40 INFO cli.CLITestHelper: Expected output:
> [Found 1 items]
> 14/05/15 16:50:40 INFO cli.CLITestHelper: Actual output: [ls:
> `/tmp/testcli_1400165386646/file1': No such file or directory
> ]
> 14/05/15 16:50:40 INFO cli.CLITestHelper: Comparator:
> [RegexpComparator]
> 14/05/15 16:50:40 INFO cli.CLITestHelper: Comparision result:
> [fail]
> 14/05/15 16:50:40 INFO cli.CLITestHelper: Expected output:
> [^-rw-r--r--( )*1( )*[a-z]*( )*hdfs( )*0( )*[0-9]{4,}-[0-9]{2,}-[0-9]{2,}
> [0-9]{2,}:[0-9]{2,}( )*/tmp/testcli_1400165386646/file1]
> 14/05/15 16:50:40 INFO cli.CLITestHelper: Actual output: [ls:
> `/tmp/testcli_1400165386646/file1': No such file or directory
> ]
> 14/05/15 16:50:40 INFO cli.CLITestHelper:
> 14/05/15 16:50:40 INFO cli.CLITestHelper:
> -------------------------------------------
> {noformat}
> The results looks as if there were someting wrong with hadoop/hdfs.
> Nevertheless when I checked this particular case manually, it worked just
> fine:
> {noformat}
> [bigtop@dhcp-lab-203 testcli]$ hadoop fs -mkdir /tmp/testcli_1400165386646
> [bigtop@dhcp-lab-203 testcli]$ hadoop fs -fs hdfs://dhcp-lab-203.local:8020
> -touchz /tmp/testcli_1400165386646/file1
> [bigtop@dhcp-lab-203 testcli]$ hadoop fs -fs hdfs://dhcp-lab-203.local:8020
> -ls /tmp/testcli_1400165386646/file1
> Found 1 items
> -rw-r--r-- 3 bigtop hdfs 0 2014-05-15 17:08
> /tmp/testcli_1400165386646/file1
> [bigtop@dhcp-lab-203 testcli]$ hadoop fs -fs hdfs://dhcp-lab-203.local:8020
> -rm /tmp/testcli_1400165386646/file1
> 14/05/15 17:08:27 INFO fs.TrashPolicyDefault: Namenode trash configuration:
> Deletion interval = 21600000 minutes, Emptier interval = 0 minutes.
> Moved: 'hdfs://dhcp-lab-203.local:8020/tmp/testcli_1400165386646/file1' to
> trash at: hdfs://dhcp-lab-203.local:8020/user/bigtop/.Trash/Current
> [bigtop@dhcp-lab-203 testcli]$
> {noformat}
> I manually checked 5 other cases with the same result: when the testcase is
> done
> manually, it works without any problems.
> Moreover I rerun all TestCLI cases 5 times, and the set of failed cases
> was always the same.
> Have anybody seen similar behaviour? I have executed TestCLI cases via wrapper
> which sets system classpath instead of maven defined enviromnent. Can this
> caused the issue, or is it likely that the problem is the bigtop tests? Also
> feel free to propose a way to debug this further.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
