hodor 1.0.2

data/topics/oozie/inspecting_jobs.txt

@@ -0,0 +1,59 @@
+INSPECTING JOBS 
+-----------------------------------------------------------------------------------------------
+The most important concept that is shared by all commands within Hodor''s Oozie namespace is the
+notion of "current job". Oozie''s job system is hierarhical. Coorinators contain workflows.
+Workflows contain actions. Actions may contain Hive jobs, decision nodes, Hadoop jobs or other
+workflows. So, it is a hierarchy, that can be many levels deep. In that respect, Oozie jobs
+present much like a file system. Unix long ago implemented a great why to traverse and inspect
+such a hierachy: ''cd'' and ''ls''. And Hodor''s Oozie namespace support the same conceptual methods.
+For example, to change to an Oozie workflow:
+
+    $ hodor oozie:change_job 0035114-151002103648730-oozie-oozi-W # Change to job with this ID
+    $ hodor oozie:change_job 14                                   # Change to job at index 14
+
+This will change the "current job" to the job indicated by the argument, but displays nothing.
+To display the state of the current job:
+
+    $ hodor oozie:display_job
+    $ hodor oozie:display_job info              # Equivalent since "info" is default attribute
+    $ hodor oozie:display_job -k                # Display only "killed" children
+    $ hodor oozie:display_job info -m "11/14"   # Display children that match "11/14" string
+    $ hodor oozie:display_job -m "11/14"        # Display children that match "11/14" string
+
+The above command will display general information (i.e. "info") about the "current job", but
+the command supports a wider range of display attributes and options. For example, you can
+change the number of children displayed, view the config settings passed in from the
+job.properties file, the current job''s log file, or the json REST response:
+
+    $ hodor oozie:display_job conf -l 100       # display 100 children
+    $ hodor oozie:display_job conf -m time      # display job properties matching ''time''
+    $ hodor oozie:display_job log -w fail.log   # display job log, write to file ''fail.log''
+    $ hodor oozie:display_job json              # display json response
+
+And if you want to change to the parent of the current job:
+
+    $ hodor oozie:change_job ..
+
+Just as file systems have a ''pwd'', Hodor''s Oozie namespace supports ''pwj'' for Path of working
+job, that will display your current position in the Oozie hierarchy of jobs.
+
+    $ hodor oozie:pwj
+
+Use of ''oozie:change_job'' is optional, because ''oozie:display_job'' will also change the
+current job, by default:
+
+    $ hodor oozie:display_job 0035114-151002103648730-oozie-oozi-W
+    $ hodor oozie:display_job 0035114-151002103648730-oozie-oozi-W log   # display log for job
+    $ hodor oozie:display_job 14 -l 50 -o 50    # info for job 14, starting at offset 50
+
+Like the previous change_job command, the display_job command will also change to the specified
+job, and then display its state. If oozie:display_job does both changing and displaying
+the job, then why should "oozie:change_job" exist? Because display_job''s behavior is
+configurable, via the ~/.hodor.yml file. If you set:
+
+    :display_job_query_mode: true
+
+in ~/.hodor.yml, then display_job does not change_job, it only displays the state of whatever
+job is current. In which case, you will need to use "oozie:change_job" and "oozie:display_job"
+in concert. So, pick which ever methodology you prefer, or that makes sense for you particular
+job inspection scenario.

data/topics/oozie/jobs.yml.txt

@@ -0,0 +1,185 @@
+The "jobs.yml" File
+---------------------------------------------------------------------------
+Within each driver directory, Hodor expects to find a "jobs.yml" file.
+Essentially a project file, that provides metadata about all the jobs
+that you have grouped together under a single drivers subdirectory. The
+"jobs.yml" file enumerates the jobs in that directory, indicates
+what workers it depends upon, which run scenario each driver expects and
+finally specifies the job property overrides each driver requires. For
+example, a typical driver directory might look like the following:
+
+
+    drivers/
+       testbench/
+          jobs.yml
+          my_test_driver.xml
+          another_test_driver.xml
+
+The "jobs.xml" file in the above directory structure enable you to 
+co-locate, deploy and run both drivers (my_test_driver and another_test_driver),
+managed by Hodor's Oozie namespace. A typical jobs.yml file might look
+something like the following:
+
+    my_test_driver:
+      deploy: workers/my_test_workflow
+      properties: |
+        scenario=hourly/incremental
+        driver=testbench/my_test_driver
+        sla_events=start_miss
+        startTime=2015-10-30T13:26Z
+        endTime=2015-10-30T13:45Z
+
+    another_test_driver:
+      deploy: workers/ingestion_flow.xml
+      properties: |
+        scenario=hourly/incremental
+        driver=testbench/another_test_driver
+        sla_events=duration_miss
+        startTime=2015-10-30T13:26Z
+        endTime=2015-10-30T13:45Z
+
+In the above jobs.yml file, there are two sections, one for each job.
+Each section must have "deploy" and "properties" key/value pairs. The deploy
+key is used by the "oozie:deploy" command to determine which worker
+directories a particular driver requires on the remote HDFS volume. For
+example, to deploy the "my_test_driver", run:
+
+     $ cd drivers/testbench
+     $ hodor oozie:deploy my_test_driver
+
+The deploy command will load the jobs.yml deploy key for the job named
+"my_test_driver", and its value to determine what the deploy command should
+upload to HDFS.
+
+The "properties" key contains properties vales that will override the
+property values in the hierarhcy of job.properties.erb files. The 
+job.properties.erb files (one of them) is expected to include the follow
+variable substitution:
+
+    FILE: job.properties.erb -------------
+    # Embed current job and run properties here
+    <%= job[:properties] %>
+
+    PWD=${drivers}/scenarios/${scenario}
+    oozie.coord.application.path=${PWD}/coordinator.xml
+    completion_flags=${drivers}/${driver}/${scenario}
+
+The "<%= job[:properties %>" variable expansion inserts the properties
+section for the particular job you name in the run_job command:
+
+    $ cd drivers/testbench
+    $ hodor oozie:run_job my_test_driver
+
+The above command loads the jobs.yml file from the current directory,
+and uses your "my_test_driver" argument to determine which yml section
+to use. The properties key from that section is then used to dynamically
+compose a combined job.properties file, that replaces the
+"<%= job[:properties] %>" with the properties for "my_test_driver".
+
+So, both the run_job command and deploy_job command use different key/value
+pairs within the same section of the jobs.yml file as input to their
+processing.
+
+Supporting Workflows Applications
+---------------------------------
+The previous example forces use of a coordinator application via its
+definition:
+
+    oozie.coord.application.path=${PWD}/coordinator.xml
+
+But what if you want your job to be a workflow application instead of
+a coordinator. In that case, modify your job.properties.erb file as
+follows:
+
+    <% if job.has_key?(:postfix) %>
+      <%= job[:postfix] %>
+    <% else %>
+      PWD=${drivers}/scenarios/${scenario}
+      oozie.coord.application.path=${PWD}/coordinator.xml
+      completion_flags=${drivers}/${driver}/${scenario}
+    <% end %>
+
+This allows you to pass in a postfix if you want to use something other
+than the standard coordinator application definition. Note: the term
+'postfix' is not a special term. It can be any name as long as you define
+it in the jobs.yml file as follows:
+
+    adhoc:
+      depends:
+      properties: |
+        run_query=guest/show_tables.hql
+      postfix: |
+        PWD=${drivers}/hivebox
+        oozie.wf.application.path=${PWD}/query.xml
+
+
+Using "Launch Markers"
+----------------------
+Another option for specifying which jobs.yml section to use for
+deploying and running a job is to use launch markers. Instead of passing
+a job name as an argument to the "oozie:deploy_job" and "oozie:run_job"
+command, you can modify the jobs.yml file with launch markers:
+
+    ^my_test_driver:
+      deploy: workers/my_test_workflow
+      properties: |
+        scenario=hourly/incremental
+        driver=testbench/my_test_driver
+        sla_events=start_miss
+        startTime=2015-10-30T13:26Z
+        endTime=2015-10-30T13:45Z
+
+    another_test_driver:
+      deploy: workers/ingestion_flow.xml
+      properties: |
+        scenario=hourly/incremental
+        driver=testbench/another_test_driver
+        sla_events=duration_miss
+        startTime=2015-10-30T13:26Z
+        endTime=2015-10-30T13:45Z
+
+Note the '^' symbol in front of "my_test_driver". This indicates to
+"oozie:deploy_job" and "oozie:run_job" that this job section is
+active. So, instead of specifying the job name on the command line,
+a short-hand is possible:
+
+    $ cd drivers/testbench
+    $ hodor oozie:deploy_job    # deploys the marked job
+    $ hodor oozie:deploy_job -c # alternate that does a clean deploy
+    $ hodor oozie:run_job       # runs the marked job
+
+Silencing Git
+-------------
+One minor annoyance with the "jobs.yml" approach, is that the file will
+change in ways that shouldn't be commited to the Git master. For example,
+if you want to change the start and end time property values, so you can
+rerun a workflow for a different time period, you don't necessarily want
+to check that in. Moreover, if you use launch markers, you don't want those
+to being commited to master either. But anytime the jobs.yml file is
+edited for either of these purposes, Git is going to bug you about
+committing your changes.
+
+This is optional, but if you want Git to ignore launch marker and
+time edits within the jobs.yml file, this is possible using "Git
+Attributes". This is a little known but highly useful feature of Git
+covered here:
+
+      https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes
+
+To utilize Git attributes to silence Git's baggering about these "throw-away"
+edits, do the following:
+
+      $ cd drivers
+      $ cat << HERE >> .gitattributes
+      jobs.yml filter=clean_jobs_yml
+      HERE
+      $ cd <repo_root>  # root of your hadoop project's git repo
+      $ cat << HERE >> .git/config
+      [include]
+        path = ../.gitconfig
+      [HERE]
+      $ cat << HERE >> .gitconfig
+      [filter "clean_jobs_yml"]
+          clean = "perl -pe \"s/^\\^//g; s/ime=20\\d\\d-\\d\\d-\\d\\d.*$/ime=<dynamic>/g\""
+          smudge = cat
+      [HERE]

data/topics/oozie/overview.txt

@@ -0,0 +1,43 @@
+Hodor's Oozie namespace provides a scriptable and easy-to-use interface to the Oozie server running
+on the target Hadoop cluster, and the workflows and coordinator jobs it is executing. Using the
+commands in this namespace, you can run oozie jobs, inspect their progress, diagnose failures,
+and kill oozie jobs, without shelling into remote machines. While many of these capabilities are
+afforded by graphical interfaces in the Hadoop ecosystem (i.e. Hue), Hodor's Oozie interface has
+several major advantages. First, Hodor's Oozie interface is more compatible with Git and modern
+software development practices, allowing you to commit your Oozie workflows to GitHub and utilize
+its teamwork features, such as branch commenting, peer reviews, pull requests etc. In addition,
+Hodor's dynamic cluster targetting and variable expansion system (via clusters.yml and jobs.yml
+files), enable you to build Oozie workflows and coordinators that can be easily and transparently
+retargetted to multiple Hadoop clusters.
+
+The Oozie namespace implements several core concepts, such as the notion of "current job",
+which is the foundation on which the "oozie:change_job" and "oozie:display_job" commands
+operate. Other concepts central to the Oozie namespace include "worker and driver workflows",
+"scenarios", the "jobs.yml" file etc. Understanding these concepts will go a long way
+toward understanding the behavior of the commands within the Oozie namespace. There are two
+ways to get more information about these core Oozie "topics". First, you can run the
+"oozie:topic <title>" command to display the help page for a particular topic. The "HELP
+TOPICS" section (shown next) provides more details about what topics are available and how to
+view them. You can also run the "oozie:topics" command to see a list of available topics.
+
+The other way to get assistance with Oozie topics is to study Hodor's rspec test suite. The
+test_repo, located at spec/test_repo, is an example Hadoop git repo that adheres to and
+implements the various conventions and concepts discussed within the Oozie topics pages. So,
+the topics page will provide you with an explanation, and the test_repo an illustration.
+
+HELP TOPICS:
+------------
+ * Inspecting Jobs - to view help for how to inspect Oozie jobs, type:
+    $ hodor oozie:topic inspecting_jobs
+ * Composing Job Properties - to view help on the job.property hierarchy, type:
+    $ hodor oozie:topic composing_job_properties
+ * Workers and Drivers - to view help on worker versus driver workflows, type:
+    $ hodor oozie:topic workers_and_drivers
+ * Driver Scenarios - to view help on driver "scenarios", type:
+    $ hodor oozie:topic driver_scenarios
+ * Blocking Coordinators - to view help on blocking vs non-blocking coordinators, type:
+    $ hodor oozie:topic blocking_coordinators
+ * Deploying and Running jobs - for information about the jobs.yml file, type:
+    $ hodor oozie:topic jobs.yml
+
+\x5

data/topics/oozie/workers_and_drivers.txt

@@ -0,0 +1,40 @@
+Kinds of Oozie Jobs: Workers versus Drivers
+---------------------------------------------------------------------------------
+The are two distinct and toplevel concerns when dealing with oozie workflows:
+
+  1. Defining the data flows and how each transforms and produces data
+  2. Giving these independent data flows a context and schedule to run on
+
+A "worker" is an Oozie workflow that does the former. It isn't concerned about
+what context it runs within, how many times it has retried, whether SLA alerts
+are being reported on its results, when it runs etc. It does one straight-forward
+job: translate input data to output data.
+
+A "driver" is an Oozie workflow and coordinator pair, that runs one or more
+workers as sub-workflows, passing them the aforementioned context as parameters.
+Drivers concern themselves with everthing workers do not, like what order
+multiple workers should run in, reporting SLA violations when its child workers
+fail, deciding between an hourly or daily run schedule etc.
+
+Hodor expects your Hadoop project get repo to be structured as follows:
+
+   <git_repo>
+      - workers/
+         - w1/
+            workflow.xml
+            hive_scripts
+            etc
+         - w2
+            workflow.xml
+            hive_scripts
+            etc.
+      - drivers/
+         - d1/
+            workflow.xml
+         - d2/
+            workflow.xml
+
+
+The workers directory contains all workers, organized as you see fit. While the
+drivers directory contains all drivers, also organized according to preference.
+

metadata

@@ -0,0 +1,455 @@
+--- !ruby/object:Gem::Specification
+name: hodor
+version: !ruby/object:Gem::Version
+  version: 1.0.2
+platform: ruby
+authors:
+- Dean Hallman
+autorequire: 
+bindir: bin
+cert_chain: []
+date: 2016-02-25 00:00:00.000000000 Z
+dependencies:
+- !ruby/object:Gem::Dependency
+  name: thor
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: 0.19.1
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: 0.19.1
+- !ruby/object:Gem::Dependency
+  name: log4r
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '1.1'
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '1.1'
+- !ruby/object:Gem::Dependency
+  name: open4
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+- !ruby/object:Gem::Dependency
+  name: terminal-table
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+- !ruby/object:Gem::Dependency
+  name: awesome_print
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+- !ruby/object:Gem::Dependency
+  name: bundler
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '1.7'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '1.7'
+- !ruby/object:Gem::Dependency
+  name: rake
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '10.0'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '10.0'
+- !ruby/object:Gem::Dependency
+  name: byebug
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+- !ruby/object:Gem::Dependency
+  name: rest-client
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+- !ruby/object:Gem::Dependency
+  name: chronic
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+- !ruby/object:Gem::Dependency
+  name: ox
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+- !ruby/object:Gem::Dependency
+  name: rspec
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+- !ruby/object:Gem::Dependency
+  name: wrong
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+- !ruby/object:Gem::Dependency
+  name: simplecov
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+- !ruby/object:Gem::Dependency
+  name: ruby-lint
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+- !ruby/object:Gem::Dependency
+  name: rubocop
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+- !ruby/object:Gem::Dependency
+  name: rspec-nc
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+- !ruby/object:Gem::Dependency
+  name: guard
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+- !ruby/object:Gem::Dependency
+  name: guard-rspec
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+- !ruby/object:Gem::Dependency
+  name: pry
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+- !ruby/object:Gem::Dependency
+  name: pry-remote
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+- !ruby/object:Gem::Dependency
+  name: pry-nav
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+description: Hodor is a ruby-based framework, API and Command Line Interface that
+  automates and simplifies the way you specify, deploy, debug and administer Hadoop
+  and Oozie solutions. Hadoop lacks a mature toolchain to manage a codebase with modern
+  software development discipline. To address this need, Hodor comprises a combination
+  of tools and conventions that enable in the Hadoop environment many of the modern
+  software development practices, and deployment facilities we take for granted in
+  normal software development.
+email:
+- rdhallman@gmail.com
+executables:
+- hodor
+extensions: []
+extra_rdoc_files: []
+files:
+- ".gitignore"
+- ".gitmodules"
+- ".rspec"
+- ".ruby-gemset"
+- ".ruby-version"
+- ".travis.yml"
+- Gemfile
+- Guardfile
+- README.md
+- Rakefile
+- bin/hodor
+- hodor.gemspec
+- lib/config/log4r_config.xml
+- lib/hodor.rb
+- lib/hodor/api/hdfs.rb
+- lib/hodor/api/oozie.rb
+- lib/hodor/api/oozie/action.rb
+- lib/hodor/api/oozie/bundle.rb
+- lib/hodor/api/oozie/coordinator.rb
+- lib/hodor/api/oozie/hadoop_job.rb
+- lib/hodor/api/oozie/job.rb
+- lib/hodor/api/oozie/materialization.rb
+- lib/hodor/api/oozie/query.rb
+- lib/hodor/api/oozie/session.rb
+- lib/hodor/api/oozie/workflow.rb
+- lib/hodor/cli.rb
+- lib/hodor/command.rb
+- lib/hodor/configuration.rb
+- lib/hodor/environment.rb
+- lib/hodor/ui/table.rb
+- lib/hodor/version.rb
+- lib/tasks/hdfs.thor
+- lib/tasks/master.thor
+- lib/tasks/oozie.thor
+- lib/tasks/sandbox.thor
+- spec/integration/api/oozie/action_spec.rb
+- spec/integration/api/oozie/bundle_spec.rb
+- spec/integration/api/oozie/coordinator_spec.rb
+- spec/integration/api/oozie/hadoop_job_spec.rb
+- spec/integration/api/oozie/job_spec.rb
+- spec/integration/api/oozie/materialization_spec.rb
+- spec/integration/api/oozie/query_spec.rb
+- spec/integration/api/oozie/session_spec.rb
+- spec/integration/api/oozie/workflow_spec.rb
+- spec/integration/api/oozie_spec.rb
+- spec/integration/fixtures/api/running_coordinators/req_resp_00.memo
+- spec/integration/fixtures/api/sample_action/req_resp_00.memo
+- spec/integration/fixtures/api/sample_action/req_resp_01.memo
+- spec/integration/fixtures/api/sample_bundle/req_resp_00.memo
+- spec/integration/fixtures/api/sample_coordinator/req_resp_00.memo
+- spec/integration/fixtures/api/sample_materialization/req_resp_00.memo
+- spec/integration/fixtures/api/sample_materialization/req_resp_01.memo
+- spec/integration/fixtures/api/sample_workflow/req_resp_00.memo
+- spec/spec_helper.rb
+- spec/support/d_v_r.rb
+- spec/support/hodor_api.rb
+- spec/unit/hodor/api/hdfs_spec.rb
+- spec/unit/hodor/api/oozie_spec.rb
+- spec/unit/hodor/environment_spec.rb
+- topics/hdfs/corresponding_paths.txt
+- topics/hdfs/overview.txt
+- topics/master/clusters.yml.txt
+- topics/master/overview.txt
+- topics/oozie/blocking_coordinators.txt
+- topics/oozie/composing_job_properties.txt
+- topics/oozie/display_job.txt
+- topics/oozie/driver_scenarios.txt
+- topics/oozie/inspecting_jobs.txt
+- topics/oozie/jobs.yml.txt
+- topics/oozie/overview.txt
+- topics/oozie/workers_and_drivers.txt
+homepage: ''
+licenses:
+- MIT
+metadata: {}
+post_install_message: 
+rdoc_options: []
+require_paths:
+- lib
+required_ruby_version: !ruby/object:Gem::Requirement
+  requirements:
+  - - ">="
+    - !ruby/object:Gem::Version
+      version: '0'
+required_rubygems_version: !ruby/object:Gem::Requirement
+  requirements:
+  - - ">="
+    - !ruby/object:Gem::Version
+      version: '0'
+requirements: []
+rubyforge_project: 
+rubygems_version: 2.5.2
+signing_key: 
+specification_version: 4
+summary: Manages Hadoop and Oozie data pipelines, through development, testing, deployment
+  and monitoring
+test_files:
+- spec/integration/api/oozie/action_spec.rb
+- spec/integration/api/oozie/bundle_spec.rb
+- spec/integration/api/oozie/coordinator_spec.rb
+- spec/integration/api/oozie/hadoop_job_spec.rb
+- spec/integration/api/oozie/job_spec.rb
+- spec/integration/api/oozie/materialization_spec.rb
+- spec/integration/api/oozie/query_spec.rb
+- spec/integration/api/oozie/session_spec.rb
+- spec/integration/api/oozie/workflow_spec.rb
+- spec/integration/api/oozie_spec.rb
+- spec/integration/fixtures/api/running_coordinators/req_resp_00.memo
+- spec/integration/fixtures/api/sample_action/req_resp_00.memo
+- spec/integration/fixtures/api/sample_action/req_resp_01.memo
+- spec/integration/fixtures/api/sample_bundle/req_resp_00.memo
+- spec/integration/fixtures/api/sample_coordinator/req_resp_00.memo
+- spec/integration/fixtures/api/sample_materialization/req_resp_00.memo
+- spec/integration/fixtures/api/sample_materialization/req_resp_01.memo
+- spec/integration/fixtures/api/sample_workflow/req_resp_00.memo
+- spec/spec_helper.rb
+- spec/support/d_v_r.rb
+- spec/support/hodor_api.rb
+- spec/unit/hodor/api/hdfs_spec.rb
+- spec/unit/hodor/api/oozie_spec.rb
+- spec/unit/hodor/environment_spec.rb