Bundles are designed to make working
with coordinators easier and managing coordinators on more holistic level.
Bundle is a higher-level oozie
abstraction that will batch a set of coordinator applications. The user will be
able to start/stop/suspend/resume/rerun in the bundle level resulting a better
and easy operational control.
More specifically, the oozie Bundle system
allows the user to define and execute a bunch of coordinator applications often
called a data pipeline. There is no explicit dependency among the coordinator
applications in a bundle. However, a user could use the data dependency of
coordinator applications to create an implicit data application pipeline.
Let's go to the top right hand corner
and click on create, this time selecting bundle as choice.
You're now prompted to enter
coordinator information. Click on Add Coordinator button and fill out with
existing coordinator information giving the full path of the coordinator XML
If you provide a full path to the coordinator XML, coordinator name will be populated on its own.
If your data pipeline consists of many
coordinators, you can chain them here by adding more coordinators and their
Since my pipeline consists
of only one coordinator, (yes not really useful, though I can see how it can be
useful when you have multiple), I'm going to click on green Add button to
Last thing left to do is enter kick off time. It expects a date, if none given, it will default to NOW, which means it will kick off immediately once submitted.
Bundle Application Definition
A bundle definition is defined in XML by a name, controls and one or more coordinator application specifications:
name: The name for the bundle job.
* controls: The control specification for the bundle.
kick-off-time: It defines when the bundle job should start and submit the coordinator applications. This field is optional and the default is NOW that means the job should start right-a-way.
coordinator: Coordinator application specification. There should be at least one coordinator application in any bundle.
name: Name of the coordinator application. It can be used for referring this application through bundle to control such as kill, suspend, rerun.
app-path: Path of the coordinator application definition in hdfs. This is a mandatory element.
configuration: A hadoop like configuration to parameterize corresponding coordinator application. This is optional.
Finally, I'm going to rename the bundle workflow
to part-10-bundle and submit it, notice I saved it to /user/centos/part-10 along with existing workflow called part-10 and coordinator called part-10-coord. All three XML files will be in the part-10 directory for organization purposes, though not required.
Same as with workflows and coordinators, I can see my bundles run on the Dashboard.
The configuration options change a bit and I no longer see an action tab, I see a coordinator tab. It also shows all my running coordinators that belong to the bundle.
The definition tab shows all required properties for bundle to run. WFM makes it easy to fill out the properties and you're no longer required to maintain a job.properties file.
Last thing I want to do is show you XML generated for this bundle.
This tutorial just goes to show you how easy it is to start learning Oozie nomenclature, before my experience with WFM, I did not know how to work with bundles, decision nodes, SLA features, etc. WFM makes working with Oozie more approachable. Until next time!