[
https://issues.apache.org/jira/browse/OOZIE-822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13439268#comment-13439268
]
Hadoop QA commented on OOZIE-822:
---------------------------------
Testing JIRA OOZIE-822
{code}
----------------------------
+1 PATCH_APPLIES
CLEAN cleaned target directories
+1 RAT
+1 the patch does not seem to introduce new RAT warnings
+1 COMPILE
+1 HEAD compiles
+1 patch compiles
+1 the patch does not seem to introduce new javac warnings
-1 TESTS - the patch failed the following testcases:
org.apache.oozie.service.TestStatusTransitService
Tests run: 874
Tests failures: 1
Tests errors: 0
----------------------------
{code}
The full output of the test-patch run is available at
https://builds.apache.org/job/oozie-trunk-precommit-build/38/
> Document that the Oozie Hive action creates a "hive-site.xml" file in the
> task's working directory
> --------------------------------------------------------------------------------------------------
>
> Key: OOZIE-822
> URL: https://issues.apache.org/jira/browse/OOZIE-822
> Project: Oozie
> Issue Type: Improvement
> Components: action
> Affects Versions: 3.2.0
> Reporter: Harsh J
> Assignee: Harsh J
> Priority: Trivial
> Attachments: OOZIE-822.patch
>
>
> In HiveMain.java, there is some code that does 'OutputStream os = new
> FileOutputStream("hive-site.xml");'. This indicates that running HiveMain
> will make it create a hive-site.xml in the launcher-mappers' working
> directory itself.
> Now if a user has <job-xml> set to a HDFS file named "hive-site.xml" too, it
> will create a symlink of this file in the working directory before the
> launcher task begins. In insecure mode this isn't an issue cause the
> LauncherMapper runs as the same user as the TT and will overwrite this file
> when it runs the above mentioned code. However, since distributed cache
> symlinks are owned by the TT-running user (mapred, say), in secure MR mode
> the LauncherMapper runs as the actual user and the code runs into a
> permission issue as it can't overwrite a file it does not own.
> We should hence document that one should not pass such a filename into the
> workflow that would make it symlink to work directory, to help avoid such a
> conflict.
> I'll think of the right words to put these in crisply and open up a review
> request.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
