[
https://issues.apache.org/jira/browse/OOZIE-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Grimes updated OOZIE-2395:
-------------------------------
Description:
Right now installing the oozie examples is cumbersome, and not very intuitive
to new users, despite the fact that they are integral to a new user becoming
familiar with how to construct workflows/coordinators/bundles.
Right now, in order to install all examples and have them be runnable right
away the user has to (possibly) replace the jobTracker/YARN RM uri, as well as
the headnode URI in each job.properties file (there are 20 or so different app
examples). Also, in order to use coordinator/bundle examples the user must
update a plethora of datetimes (although generating these in the examples could
be considered out of scope and more difficult)
Personally, in my Bigtop with oozie 4.2.0 i'm using a script to untar the
examples, replace all jobtracker and namenode uri's with ones passed in (or set
in an install-oozie-examples-env.sh script), and then upload them into hdfs
under the users account. This allows me to quickly install examples on cluster
spin-up, and run them to verify oozies operability.
I'd like to open this to discussion of implementation details, as I'm not sure
if this would be a change the Oozie community would be open to, or if anyone
has any ideas as to the best way to implement this.
was:
Right now installing the oozie examples is cumbersome, and not very intuitive
to new users, despite the fact that they are integral to a new user becoming
familiar with how to construct workflows/coordinators/bundles.
Right now, in order to install all examples and have them be runnable right
away the user has to (possibly) replace the jobTracker/YARN RM uri, as well as
the headnode URI in each job.properties file (there are 20 or so different app
examples). Also, in order to use coordinator/bundle examples the user must
update a plethora of datetimes (although generating these in the examples could
be considered out of scope and more difficult)
Personally, in my Bigtop with oozie 4.2.0 i'm using a script to replace all
jobtracker and namenode uri's with ones passed in, or set in an
install-oozie-examples-env.sh script. This allows me to quickly on cluster
spin-up, install examples, and run them to verify oozies operability.
I'd like to open this to discussion of implementation details, as I'm not sure
if this would be a change the Oozie community would be open to, or if anyone
has any ideas as to the best way to implement this.
> Add easy method to install example files into sharelib
> ------------------------------------------------------
>
> Key: OOZIE-2395
> URL: https://issues.apache.org/jira/browse/OOZIE-2395
> Project: Oozie
> Issue Type: New Feature
> Components: examples
> Affects Versions: trunk
> Reporter: Mike Grimes
> Priority: Minor
> Fix For: trunk
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Right now installing the oozie examples is cumbersome, and not very intuitive
> to new users, despite the fact that they are integral to a new user becoming
> familiar with how to construct workflows/coordinators/bundles.
> Right now, in order to install all examples and have them be runnable right
> away the user has to (possibly) replace the jobTracker/YARN RM uri, as well
> as the headnode URI in each job.properties file (there are 20 or so different
> app examples). Also, in order to use coordinator/bundle examples the user
> must update a plethora of datetimes (although generating these in the
> examples could be considered out of scope and more difficult)
> Personally, in my Bigtop with oozie 4.2.0 i'm using a script to untar the
> examples, replace all jobtracker and namenode uri's with ones passed in (or
> set in an install-oozie-examples-env.sh script), and then upload them into
> hdfs under the users account. This allows me to quickly install examples on
> cluster spin-up, and run them to verify oozies operability.
> I'd like to open this to discussion of implementation details, as I'm not
> sure if this would be a change the Oozie community would be open to, or if
> anyone has any ideas as to the best way to implement this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
