Problem in oozie input path . How do I configure the oozie in cloudera manager,input path as s3n.

[#1]

My input path in s3n,

s3n://xxx-xxx/20130813/08

My oozie configuration show as ,

hdfs://xxx.internal:8020/s3n://xxx-xxx/20130813/08

[#2]

The link hdfs://xxx.internal:8020/s3n://xxx-xxx/20130813/08 requires a login.

[#3]

Sorry, my question is through Hue in cloudera manager  i'm running the oozie job .And I can able to access the hdfs,my question is to connect the another instance  Amazon  as s3n://xxx  to connect ..

[#4]

The input path is required to be to HDFS, not S3. S3 is not the same as HDFS.

[#5]

---

@dvohra wrote:

The input path is required to be to HDFS, not S3. S3 is not the same as HDFS.

---

This isn't true. Depending on what you're doing with Oozie, S3 is supported just fine as an input or output location.

[#6]

This isn't true. Depending on what you're doing with Oozie, S3 is supported just fine as an input or output location.

Doesn't the coordinator expect the input path to be on HDFS as hdfs://{nameNode} is prepended automatically? The workflow.xml is on the HDFS? Isn't the workflow.xml required to be on the HDFS?

[#7 · Accepted solution]

---

@dvohra wrote:

This isn't true. Depending on what you're doing with Oozie, S3 is supported just fine as an input or output location.

Doesn't the coordinator expect the input path to be on HDFS as hdfs://{nameNode} is prepended automatically? The workflow.xml is on the HDFS? Isn't the workflow.xml required to be on the HDFS?

---

Yes unfortunately coordinators currently poll inputs over HDFS alone, which is a limitation. However, writing simple WF actions to work over S3 is still possible.

Yes, WFs should reside on HDFS, as Oozie views it as its central DFS. Similar to how MR requires a proper DFS to run. But this shouldn't impair simple I/O operations done over an external FS such as S3.

I think Romain has covered the relevant JIRAs for tracking removal of this limitation.

[#8]

Is there any updates to this Jira item? Is there a way now to specify an S3n:// location for input or output directories in Oozie workflow without the location being prepended by "hdfs"?

[#9]

Yes, https://issues.cloudera.org/browse/HUE-1501 is in Hue 3.5 or CDH5 beta 2 in one month (and CDH5 in 2 months).

If it is urgent you could try to patch your Hue with the fix: https://issues.cloudera.org/browse/HUE-1501?focusedCommentId=19417&page=com.atlassian.jira.plugin.sy...

[#10]

Thank you.  However I think my question is a little different than that addresses.  I am trying to specify an input or output directory in form "s3://..." in an Oozie workflow itself (as an input to a hadoop map reduce job).  Do you know if this should work? I get an error that says the path can't have "s3" in it.

[#11]

Yes, it should work, cf. above users using it with no problem. What is your Oozie version?

[#12]

I'm using "oozie-3.3.2-cdh4.5.0". The installation is working fine when input/output paths are specified in form "hdfs://…." but when specified with either "s3://…" or "s3n://" we get the following error in the logs:

Scheme of ʼs3n://...ʼ is not supported.

Where "…" equals path to input/output, verified there, verified working with hadoop commands in console.

Anything you know of I can look at?

[#13]

Nevermind, I got it.

The solution was a mix of upgrading the version (to previously listed version) AND adding the supported filesystems property back in.

thanks!

[#14]

Glad to hear!

[#15]

---

@Ashok wrote:

My input path in s3n,

s3n://xxx-xxx/20130813/08

My oozie configuration show as ,

hdfs://xxx.internal:8020/s3n://xxx-xxx/20130813/08

---

Can you share your workflow.xml for us to validate?

If you're passing an S3 input or output path, simply ensure your workflow does not template it as ${nameNode}/${input} or something like that. That way you're prepending a HDFS URI to your already-an-uri path. This could most likely be your issue.

[#16]

In coordinator jobs i'm passing the dataset  uri template as 

s3n://xxx-xxx/${YEAR}${MONTH}${DAY}/${HOUR}

and coord:dataOut as 

<property>
<name>in_folder</name>
<value>${coord:dataOut('in_folder')}</value>
</property>

and my workflow.xml  input as 

${in_folder}

when I submit the  coordinator job it automatically preappend  the configuration like:

${nameNode}s3n://xxx-xxx/${YEAR}${MONTH}${DAY}/${HOUR}

[#17]

Good to know, Hue Coodinators are prepended only with hdfs.

Is https://issues.apache.org/jira/browse/OOZIE-426 finished?

[#18]

FWIW, the same job works fine as a workflow when submitted via Hue. In this case, we manually pass the input (S3) and output (hdfs) locations and the job runs successfuly - thus establishing that the problem is not with S3 support. The problem is when we let the co-ordinator pass this input (via a computed datasource) does it automatically prepend hdfs://{nameNode} in front of the s3n://<> URI. Hope this clarifies.

[#19]

Ok this clarifies a lot! I updated https://issues.cloudera.org/browse/HUE-1501.

[#20]

Thanks. Is this considered as a bug? If yes, what are some workarounds that we can follow for now? Any help is appreciated.