[
https://issues.apache.org/jira/browse/OOZIE-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13900953#comment-13900953
]
jay vyas commented on OOZIE-1695:
---------------------------------
Good point, so is it possible to support the "name-node" "job-tracker"
semantics for backward compatibility and still eliminate them as requirements?
I think they are confusing, even HDFS users - because they give HDFS users the
impression that , for example, they can't port their workflows to MR2, or to
other file systems.
> Generic HCFS supported integration path
> ----------------------------------------
>
> Key: OOZIE-1695
> URL: https://issues.apache.org/jira/browse/OOZIE-1695
> Project: Oozie
> Issue Type: Task
> Reporter: jay vyas
>
> The dizzying OOZIE-426 JIRA indicates that at the moment it is not clear
> wether oozie does, or doesn't, support any HCFS file system.
> - the good news is, after some digging : It does !
> So we have two tasks, mostly documentation i guess, but possibly some
> modifications in code/comments would be nice as well to clarify things
> further for developers:
> - So now we need to all agree on and document the "right" way to add file
> system plugins into Oozie. Hopefully we can do so using semantics which is
> not dependant on HDFS/S3 to avoid confusion.
> - In addition, Some clarity on why and how the "nameNode" parameter is
> enforced as part of the XML schema for java tasks should also be clarified.
> Clearly that is a bug since oozie supports non-HDFS deployments.
> Specifically, it appears that in the
> http://oozie.apache.org/docs/3.2.0-incubating/WorkflowFunctionalSpec.html
> "The java action has to be configured with the job-tracker, name-node, main
> Java class, JVM options and arguments.".....
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
