You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@oozie.apache.org by an...@apache.org on 2018/09/14 14:39:03 UTC
[20/21] oozie git commit: OOZIE-2734 amend [docs] Switch from TWiki
to Markdown (asalamon74 via andras.piros, pbacsko, gezapeti)
http://git-wip-us.apache.org/repos/asf/oozie/blob/6a6f2199/docs/src/site/markdown/AG_Monitoring.md
----------------------------------------------------------------------
diff --git a/docs/src/site/markdown/AG_Monitoring.md b/docs/src/site/markdown/AG_Monitoring.md
new file mode 100644
index 0000000..4877dfc
--- /dev/null
+++ b/docs/src/site/markdown/AG_Monitoring.md
@@ -0,0 +1,199 @@
+
+
+[::Go back to Oozie Documentation Index::](index.html)
+
+# Oozie Monitoring
+
+<!-- MACRO{toc|fromDepth=1|toDepth=4} -->
+
+## Oozie Instrumentation
+
+Oozie code is instrumented in several places to collect runtime metrics. The instrumentation data can be used to
+determine the health of the system, performance of the system, and to tune the system.
+
+This comes in two flavors:
+
+ * metrics (by default enabled since 5.0.0)
+ * instrumentation (deprecated and by default disabled since 5.0.0)
+
+The instrumentation is accessible via the Admin web-services API (see the [metrics](WebServicesAPI.html#Oozie_Metrics) and
+[instrumentation](WebServicesAPI.html#Oozie_Instrumentation) Web Services API documentations for more details) and is also written on
+regular intervals to an instrumentation log.
+
+Instrumentation data includes variables, samplers, timers and counters.
+
+### Variables
+
+ * oozie
+ * version: Oozie build version.
+
+ * configuration
+ * config.dir: directory from where the configuration files are loaded. If null, all configuration files are loaded from the classpath. [Configuration files are described here](AG_Install.html#Oozie_Configuration).
+ * config.file: the Oozie custom configuration for the instance.
+
+ * jvm
+ * free.memory
+ * max.memory
+ * total.memory
+
+ * locks
+ * locks: Locks are used by Oozie to synchronize access to workflow and action entries when the database being used does not support 'select for update' queries. (MySQL supports 'select for update').
+
+ * logging
+ * config.file: Log4j '.properties' configuration file.
+ * from.classpath: whether the config file has been read from the classpath or from the config directory.
+ * reload.interval: interval at which the config file will be reloaded. 0 if the config file will never be reloaded, when loaded from the classpath is never reloaded.
+
+### Samplers - Poll data at a fixed interval (default 1 sec) and report an average utilization over a longer period of time (default 60 seconds).
+
+Poll for data over fixed interval and generate an average over the time interval. Unless specified, all samplers in
+Oozie work on a 1 minute interval.
+
+ * callablequeue
+ * delayed.queue.size: The size of the delayed command queue.
+ * queue.size: The size of the command queue.
+ * threads.active: The number of threads processing callables.
+
+ * jdbc:
+ * connections.active: Active Connections over the past minute.
+
+ * webservices: Requests to the Oozie HTTP endpoints over the last minute.
+ * admin
+ * callback
+ * job
+ * jobs
+ * requests
+ * version
+
+### Counters - Maintain statistics about the number of times an event has occurred, for the running Oozie instance. The values are reset if the Oozie instance is restarted.
+
+ * action.executors - Counters related to actions.
+ * [action_type]#action.[operation_performed] (start, end, check, kill)
+ * [action_type]#ex.[exception_type] (transient, non-transient, error, failed)
+ * e.g.
+```
+ssh#action.end: 306
+ssh#action.start: 316
+```
+
+ * callablequeue - count of events in various execution queues.
+ * delayed.queued: Number of commands queued with a delay.
+ * executed: Number of executions from the queue.
+ * failed: Number of queue attempts which failed.
+ * queued: Number of queued commands.
+
+ * commands: Execution Counts for various commands. This data is generated for all commands.
+ * action.end
+ * action.notification
+ * action.start
+ * callback
+ * job.info
+ * job.notification
+ * purge
+ * signal
+ * start
+ * submit
+
+ * jobs: Job Statistics
+ * start: Number of started jobs.
+ * submit: Number of submitted jobs.
+ * succeeded: Number of jobs which succeeded.
+ * kill: Number of killed jobs.
+
+ * authorization
+ * failed: Number of failed authorization attempts.
+
+ * webservices: Number of request to various web services along with the request type.
+ * failed: total number of failed requests.
+ * requests: total number of requests.
+ * admin
+ * admin-GET
+ * callback
+ * callback-GET
+ * jobs
+ * jobs-GET
+ * jobs-POST
+ * version
+ * version-GET
+
+### Timers - Maintain information about the time spent in various operations.
+
+ * action.executors - Counters related to actions.
+ * [action_type]#action.[operation_performed] (start, end, check, kill)
+
+ * callablequeue
+ * time.in.queue: Time a callable spent in the queue before being processed.
+
+ * commands: Generated for all Commands.
+ * action.end
+ * action.notification
+ * action.start
+ * callback
+ * job.info
+ * job.notification
+ * purge
+ * signal
+ * start
+ * submit
+
+ * db - Timers related to various database operations.
+ * create-workflow
+ * load-action
+ * load-pending-actions
+ * load-running-actions
+ * load-workflow
+ * load-workflows
+ * purge-old-workflows
+ * save-action
+ * update-action
+ * update-workflow
+
+ * webservices
+ * admin
+ * admin-GET
+ * callback
+ * callback-GET
+ * jobs
+ * jobs-GET
+ * jobs-POST
+ * version
+ * version-GET
+
+## Oozie JVM Thread Dump
+The `admin/jvminfo.jsp` servlet can be used to get some basic jvm stats and thread dump.
+For eg: `http://localhost:11000/oozie/admin/jvminfo.jsp?cpuwatch=1000&threadsort=cpu`. It takes the following optional
+query parameters:
+
+ * threadsort - The order in which the threads are sorted for display. Valid values are name, cpu, state. Default is state.
+ * cpuwatch - Time interval in milliseconds to monitor cpu usage of threads. Default value is 0.
+
+## Monitoring Database Schema Integrity
+
+Oozie stores all of its state in a database. Hence, ensuring that the database schema is correct is very important to ensuring that
+Oozie is healthy and behaves correctly. To help with this, Oozie includes a `SchemaCheckerService` which periodically runs and
+performs a series of checks on the database schema. More specifically, it checks the following:
+
+ * Existence of the required tables
+ * Existence of the required columns in each table
+ * Each column has the correct type and default value
+ * Existence of the required primary keys and indexes
+
+After each run, the `SchemaCheckerService` writes the result of the checks to the Oozie log and to the "schema-checker.status"
+instrumentation variable. If there's a problem, it will be logged at the ERROR level, while correct checks are logged at the DEBUG
+level.
+
+By default, the `SchemaCheckerService` runs every 7 days. This can be configured
+by `oozie.service.SchemaCheckerService.check.interval`
+
+By default, the `SchemaCheckerService` will consider "extra" tables, columns, and indexes to be incorrect. Advanced users who have
+added additional tables, columns, and indexes can tell Oozie to ignore these by
+setting `oozie.service.SchemaCheckerService.ignore.extras` to `false`.
+
+The `SchemaCheckerService` currently only supports MySQL, PostgreSQL, and Oracle databases. SQL Server and Derby are currently not
+supported.
+
+When Oozie HA is enabled, only one of the Oozie servers will perform the checks.
+
+[::Go back to Oozie Documentation Index::](index.html)
+
+
http://git-wip-us.apache.org/repos/asf/oozie/blob/6a6f2199/docs/src/site/markdown/AG_OozieUpgrade.md
----------------------------------------------------------------------
diff --git a/docs/src/site/markdown/AG_OozieUpgrade.md b/docs/src/site/markdown/AG_OozieUpgrade.md
new file mode 100644
index 0000000..ec24011
--- /dev/null
+++ b/docs/src/site/markdown/AG_OozieUpgrade.md
@@ -0,0 +1,86 @@
+
+
+[::Go back to Oozie Documentation Index::](index.html)
+
+# Oozie Upgrade
+
+<!-- MACRO{toc|fromDepth=1|toDepth=4} -->
+
+## Preparation
+
+Make sure there are not Workflows in RUNNING or SUSPENDED status, otherwise the database upgrade will fail.
+
+Shutdown Oozie and backup the Oozie database.
+
+Copy the oozie-site.xml from your current setup.
+
+## Oozie Server Upgrade
+
+Expand the new Oozie tarball in a new location.
+
+Edit the new `oozie-site.xml` setting all custom properties values from the old `oozie-site.xml`
+
+IMPORTANT: From Oozie 2.x to Oozie 3.x the names of the database configuration properties have
+changed. Their prefix has changed from `oozie.service.StoreService.*` to `oozie.service.JPAService.*`.
+Make sure you are using the new prefix.
+
+After upgrading the Oozie server, the `oozie-setup.sh` MUST be rerun before starting the
+upgraded Oozie server.
+
+Oozie database migration is required when there Oozie database schema changes, like
+upgrading from Oozie 2.x to Oozie 3.x.
+
+Configure the oozie-site.xml with the correct database configuration properties as
+explained in the 'Database Configuration' section in [Oozie Install](AG_Install.html).
+
+Once `oozie-site.xml` has been configured with the database configuration execute the `ooziedb.sh`
+command line tool to upgrade the database:
+
+
+```
+$ bin/ooziedb.sh upgrade -run
+
+Validate DB Connection.
+DONE
+Check DB schema exists
+DONE
+Check OOZIE_SYS table does not exist
+DONE
+Verify there are not active Workflow Jobs
+DONE
+Create SQL schema
+DONE
+DONE
+Create OOZIE_SYS table
+DONE
+Upgrade COORD_JOBS new columns default values.
+DONE
+Upgrade COORD_JOBS & COORD_ACTIONS status values.
+DONE
+Table 'WF_ACTIONS' column 'execution_path', length changed to 1024
+DONE
+
+Oozie DB has been upgraded to Oozie version '3.2.0'
+
+The SQL commands have been written to: /tmp/ooziedb-5737263881793872034.sql
+
+$
+```
+
+The new version of the Oozie server is ready to be started.
+
+NOTE: If using MySQL or Oracle, copy the corresponding JDBC driver JAR file to the `libext/` directory before running
+the `ooziedb.sh` command line tool.
+
+NOTE: If instead using the '-run' option, the `-sqlfile <FILE>` option is used, then all the
+database changes will be written to the specified file and the database won't be modified.
+
+## Oozie Client Upgrade
+
+While older Oozie clients work with newer Oozie server, to have access to all the
+functionality of the Oozie server the same version of Oozie client should be installed
+and used by users.
+
+[::Go back to Oozie Documentation Index::](index.html)
+
+
http://git-wip-us.apache.org/repos/asf/oozie/blob/6a6f2199/docs/src/site/markdown/BundleFunctionalSpec.md
----------------------------------------------------------------------
diff --git a/docs/src/site/markdown/BundleFunctionalSpec.md b/docs/src/site/markdown/BundleFunctionalSpec.md
new file mode 100644
index 0000000..5301429
--- /dev/null
+++ b/docs/src/site/markdown/BundleFunctionalSpec.md
@@ -0,0 +1,418 @@
+
+
+[::Go back to Oozie Documentation Index::](index.html)
+
+-----
+
+# Oozie Bundle Specification
+
+The goal of this document is to define a new oozie abstraction called bundle system specialized in submitting and maintaining a set of coordinator applications.
+
+
+<!-- MACRO{toc|fromDepth=1|toDepth=4} -->
+
+## Changelog
+
+## 1. Bundle Overview
+
+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.
+
+
+## 2. Definitions
+
+**Kick-off-time:** The time when a bundle should start and submit coordinator applications.
+
+**Bundle Application:** A bundle application defines a set of coordinator applications and when to start those. Normally, bundle applications are parameterized. A bundle application is written in XML.
+
+**Bundle Job:** A bundle job is an executable instance of a bundle application. A job submission is done by submitting a job configuration that resolves all parameters in the application definition.
+
+**Bundle Definition Language:** The language used to describe bundle applications.
+
+## 3. Expression Language for Parameterization
+
+Bundle application definitions can be parameterized with variables.
+
+At job submission time all the parameters are resolved into concrete values.
+
+The parameterization of bundle definitions is done using JSP Expression Language syntax from the [JSP 2.0 Specification (JSP.2.3)](http://jcp.org/aboutJava/communityprocess/final/jsr152/index.html), allowing not only to support variables as parameters but also complex expressions.
+
+EL expressions can be used in XML attribute values and XML text element values. They cannot be used in XML element and XML attribute names.
+
+
+## 4. Bundle Job
+
+### 4.1. Bundle Job Status
+
+At any time, a bundle job is in one of the following status: **PREP, RUNNING, RUNNINGWITHERROR, SUSPENDED, PREPSUSPENDED, SUSPENDEDWITHERROR, PAUSED, PAUSEDWITHERROR, PREPPAUSED, SUCCEEDED, DONEWITHERROR, KILLED, FAILED**.
+
+### 4.2. Transitions of Bundle Job Status
+
+Valid bundle job status transitions are:
+
+ * **PREP --> PREPSUSPENDED | PREPPAUSED | RUNNING | KILLED**
+ * **RUNNING --> RUNNINGWITHERROR | SUSPENDED | PAUSED | SUCCEEDED | KILLED**
+ * **RUNNINGWITHERROR --> RUNNING | SUSPENDEDWITHERROR | PAUSEDWITHERROR | DONEWITHERROR | FAILED | KILLED**
+ * **PREPSUSPENDED --> PREP | KILLED**
+ * **SUSPENDED --> RUNNING | KILLED**
+ * **SUSPENDEDWITHERROR --> RUNNINGWITHERROR | KILLED**
+ * **PREPPAUSED --> PREP | KILLED**
+ * **PAUSED --> SUSPENDED | RUNNING | KILLED**
+ * **PAUSEDWITHERROR --> SUSPENDEDWITHERROR | RUNNINGWITHERROR | KILLED**
+
+### 4.3. Details of Status Transitions
+When a bundle job is submitted, oozie parses the bundle job XML. Oozie then creates a record for the bundle with status **PREP** and returns a unique ID.
+
+When a user requests to suspend a bundle job that is in **PREP** state, oozie puts the job in status **PREPSUSPENDED**. Similarly, when pause time reaches for a bundle job with **PREP** status, oozie puts the job in status **PREPPAUSED**.
+
+Conversely, when a user requests to resume a **PREPSUSPENDED** bundle job, oozie puts the job in status **PREP**. And when pause time is reset for a bundle job that is in **PREPPAUSED** state, oozie puts the job in status **PREP**.
+
+There are two ways a bundle job could be started.
+
+* If `kick-off-time` (defined in the bundle xml) reaches. The default value is null which means starts coordinators NOW.
+
+* If user sends a start request to START the bundle.
+
+When a bundle job starts, oozie puts the job in status **RUNNING** and it submits all the coordinator jobs. If any coordinator job goes to **FAILED/KILLED/DONEWITHERROR** state, the bundle job is put in **RUNNINGWITHERROR**
+
+When a user requests to kill a bundle job, oozie puts the job in status **KILLED** and it sends kill to all submitted coordinator jobs.
+
+When a user requests to suspend a bundle job that is in **RUNNING** status, oozie puts the job in status **SUSPENDED** and it suspends all submitted coordinator jobs. Similarly, when a user requests to suspend a bundle job that is in **RUNNINGWITHERROR** status, oozie puts the job in status **SUSPENDEDWITHERROR** and it suspends all submitted coordinator jobs.
+
+When pause time reaches for a bundle job that is in **RUNNING** status, oozie puts the job in status **PAUSED**. When pause time reaches for a bundle job that is in **RUNNINGWITHERROR** status, oozie puts the job in status **PAUSEDWITHERROR**.
+
+Conversely, when a user requests to resume a **SUSPENDED** bundle job, oozie puts the job in status **RUNNING**. Similarly, when a user requests to resume a **SUSPENDEDWITHERROR** bundle job, oozie puts the job in status **RUNNINGWITHERROR**. And when pause time is reset for a bundle job and job status is **PAUSED**, oozie puts the job in status **RUNNING**. Similarly, when the pause time is reset for a bundle job and job status is **PAUSEDWITHERROR**, oozie puts the job in status **RUNNINGWITHERROR**
+
+When all the coordinator jobs finish, oozie updates the bundle status accordingly. If all coordinators reaches to the _same_ terminal state, bundle job status also move to the same status. For example, if all coordinators are **SUCCEEDED**, oozie puts the bundle job into **SUCCEEDED** status. However, if all coordinator jobs don't finish with the same status, oozie puts the bundle job into **DONEWITHERROR**.
+
+
+### 4.3. Bundle Application Definition
+A bundle definition is defined in XML by a name, controls and one or more coordinator application specifications:
+
+ * **<font color="#0000ff"> name: </font>** The name for the bundle job.
+ * **<font color="#0000ff"> controls: </font>** The control specification for the bundle.
+ * **<font color="#0000ff"> kick-off-time: </font>** 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.
+ * **<font color="#0000ff"> coordinator: </font>** Coordinator application specification. There should be at least one coordinator application in any bundle.
+ * **<font color="#0000ff"> name: </font>** Name of the coordinator application. It can be used for referring this application through bundle to control such as kill, suspend, rerun.
+ * **<font color="#0000ff"> enabled: </font>** Enabled can be used to enable or disable a coordinator. It is optional. The default value for enabled is true.
+ * **<font color="#0000ff"> app-path: </font>** Path of the coordinator application definition in hdfs. This is a mandatory element.
+ * **<font color="#0000ff"> configuration: </font>** A hadoop like configuration to parameterize corresponding coordinator application. This is optional.
+ * **<font color="#0000ff"> Parameterization: </font>** Configuration properties that are a valid Java identifier, [A-Za-z_][0-9A-Za-z_]*, are available as `${NAME}` variables within the bundle application definition. Configuration properties that are not a valid Java identifier, for example `job.tracker`, are available via the `${bundle:conf(String name)}` function. Valid Java identifier properties are available via this function as well.
+
+
+**<font color="#800080">Syntax: </font>**
+
+
+```
+ <bundle-app name=[NAME] xmlns='uri:oozie:bundle:0.1'>
+ <controls>
+ <kick-off-time>[DATETIME]</kick-off-time>
+ </controls>
+ <coordinator name=[NAME] enabled=[TRUE | FALSE] >
+ <app-path>[COORD-APPLICATION-PATH]</app-path>
+ <configuration>
+ <property>
+ <name>[PROPERTY-NAME]</name>
+ <value>[PROPERTY-VALUE]</value>
+ </property>
+ ...
+ </configuration>
+ </coordinator>
+ ...
+</bundle-app>
+```
+
+
+**<font color="#008000"> Examples: </font>**
+
+**A Bundle Job that maintains two coordinator applications:**
+
+
+```
+<bundle-app name='APPNAME' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xmlns='uri:oozie:bundle:0.1'>
+ <controls>
+ <kick-off-time>${kickOffTime}</kick-off-time>
+ </controls>
+ <coordinator name="${bundle:conf('coordName1')}" >
+ <app-path>${appPath}</app-path>
+ <configuration>
+ <property>
+ <name>startTime1</name>
+ <value>${bundle:conf('coord1.startTime1')}</value>
+ </property>
+ <property>
+ <name>endTime1</name>
+ <value>${END_TIME}</value>
+ </property>
+ </configuration>
+ </coordinator>
+ <coordinator name='coordJobFromBundle2' >
+ <app-path>${appPath2}</app-path>
+ <configuration>
+ <property>
+ <name>startTime2</name>
+ <value>${START_TIME2}</value>
+ </property>
+ <property>
+ <name>endTime2</name>
+ <value>${END_TIME2}</value>
+ </property>
+ </configuration>
+ </coordinator>
+</bundle-app>
+```
+
+### 4.4. Bundle Formal Parameters
+As of schema 0.2, a list of formal parameters can be provided which will allow Oozie to verify, at submission time, that said
+properties are actually specified (i.e. before the job is executed and fails). Default values can also be provided.
+
+**Example:**
+
+The previous Bundle Job application definition with formal parameters:
+
+
+```
+<bundle-app name='APPNAME' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xmlns='uri:oozie:bundle:0.2'>
+ <parameters>
+ <property>
+ <name>appPath</name>
+ </property>
+ <property>
+ <name>appPath2</name>
+ <value>hdfs://foo:8020/user/joe/job/job.properties</value>
+ </property>
+ </parameters>
+ <controls>
+ <kick-off-time>${kickOffTime}</kick-off-time>
+ </controls>
+ <coordinator name='coordJobFromBundle1' >
+ <app-path>${appPath}</app-path>
+ <configuration>
+ <property>
+ <name>startTime1</name>
+ <value>${START_TIME}</value>
+ </property>
+ <property>
+ <name>endTime1</name>
+ <value>${END_TIME}</value>
+ </property>
+ </configuration>
+ </coordinator>
+ <coordinator name='coordJobFromBundle2' >
+ <app-path>${appPath2}</app-path>
+ <configuration>
+ <property>
+ <name>startTime2</name>
+ <value>${START_TIME2}</value>
+ </property>
+ <property>
+ <name>endTime2</name>
+ <value>${END_TIME2}</value>
+ </property>
+ </configuration>
+ </coordinator>
+</bundle-app>
+```
+
+In the above example, if `appPath` is not specified, Oozie will print an error message instead of submitting the job. If
+`appPath2` is not specified, Oozie will use the default value, `hdfs://foo:8020/user/joe/job/job.properties`.
+
+
+## 5. User Propagation
+
+When submitting a bundle job, the configuration must contain a `user.name` property. If security is enabled, Oozie must ensure that the value of the `user.name` property in the configuration match the user credentials present in the protocol (web services) request.
+
+When submitting a bundle job, the configuration may contain the `oozie.job.acl` property (the `group.name` property
+has been deprecated). If authorization is enabled, this property is treated as as the ACL for the job, it can contain
+user and group IDs separated by commas.
+
+The specified user and ACL are assigned to the created bundle job.
+
+Oozie must propagate the specified user and ACL to the system executing its children jobs (coordinator jobs).
+
+## 6. Bundle Application Deployment
+
+A bundle application consist exclusively of bundle application definition and associated coordinator application specifications. They must be installed in an HDFS directory. To submit a job for a bundle application, the full HDFS path to bundle application definition must be specified.
+
+### 6.1. Organizing Bundle Applications
+
+TBD.
+
+## 7. Bundle Job Submission
+
+When a bundle job is submitted to Oozie, the submitter must specified all the required job properties plus the HDFS path to the bundle application definition for the job.
+
+The bundle application definition HDFS path must be specified in the 'oozie.bundle.application.path' job property.
+
+All the bundle job properties, the HDFS path for the bundle application, the 'user.name' and 'oozie.job.acl' must be
+submitted to the Oozie using an XML configuration file (Hadoop XML configuration file).
+
+**<font color="#008000"> Example: </font>**:
+
+
+```
+<?xml version="1.0" encoding="UTF-8"?>
+<configuration>
+ <property>
+ <name>user.name</name>
+ <value>joe</value>
+ </property>
+ <property>
+ <name>oozie.bundle.application.path</name>
+ <value>hdfs://foo:8020/user/joe/mybundles/hello-bundle1.xml</value>
+ </property>
+ ...
+</configuration>
+```
+
+## 8. Bundle Rerun
+### 8.1 Rerunning a Bundle Job
+Oozie provides a way of rerunning a bundle job. The user could request to rerun a subset of coordinators within a bundle by defining a list of coordinator's names. In addition, a user could define a list of dates or ranges of dates (in UTC format) to rerun for those time windows.
+There is a way of asking whether to cleanup all output directories before rerun. By default, oozie will remove all output directories. Moreover, there is an option by which a user could ask to re-calculate the dynamic input directories defined by latest function in coordinators.
+
+### 8.2 Rerun Arguments
+
+
+```
+$oozie job -rerun <bundle_Job_id> [-coordinator <list of coordinator name separate by comma>
+[-date 2009-01-01T01:00Z::2009-05-31T23:59Z, 2009-11-10T01:00Z, 2009-12-31T22:00Z]
+ [-nocleanup] [-refresh]
+```
+
+ * The `rerun` option reruns a bundle job that is *not* in (`KILLED`, `FAILED`, `PREP`, `PREPPAUSED`, `PREPSUSPENDED`).
+ * Rerun a bundle job that is in `PAUSED` state will reset the paused time.
+ * The option -coordinator determines the name of coordinator that will be rerun. By default all coordinators are rerun.
+ * Multiple ranges can be used in -date. See the above examples.
+ * The dates specified in -date must be UTC.
+ * If -nocleanup is given, corresponding coordinator directories will not be removed; otherwise the 'output-event' will be deleted.
+ * If -refresh is set, new dataset is re-evaluated for latest() and future() for the corresponding coordinators.
+ * If -refresh is set, all dependencies will be re-checked; otherwise only missed dependencies will be checked for the corresponding coordinators.
+
+
+After the command is executed the rerun bundle job will be in `RUNNING` status.
+
+Refer to the [Rerunning Coordinator Actions](DG_CoordinatorRerun.html) for details on rerun of coordinator job.
+
+
+## Appendixes
+
+### Appendix A, Oozie Bundle XML-Schema
+
+#### Oozie Bundle Schema 0.1
+
+
+```
+<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:bundle="uri:oozie:bundle:0.1"
+ elementFormDefault="qualified" targetNamespace="uri:oozie:bundle:0.1">
+
+ <xs:element name="bundle-app" type="bundle:BUNDLE-APP"/>
+ <xs:simpleType name="IDENTIFIER">
+ <xs:restriction base="xs:string">
+ <xs:pattern value="([a-zA-Z]([\-_a-zA-Z0-9])*){1,39})"/>
+ </xs:restriction>
+ </xs:simpleType>
+ <xs:complexType name="BUNDLE-APP">
+ <xs:sequence>
+ <xs:element name="controls" type="bundle:CONTROLS" minOccurs="0" maxOccurs="1"/>
+ <xs:element name="coordinator" type="bundle:COORDINATOR" minOccurs="1" maxOccurs="unbounded"/>
+ </xs:sequence>
+ <xs:attribute name="name" type="bundle:IDENTIFIER" use="required"/>
+ </xs:complexType>
+ <xs:complexType name="CONTROLS">
+ <xs:sequence minOccurs="0" maxOccurs="1">
+ <xs:element name="kick-off-time" type="xs:string" minOccurs="0" maxOccurs="1"/>
+ </xs:sequence>
+ </xs:complexType>
+ <xs:complexType name="COORDINATOR">
+ <xs:sequence minOccurs="1" maxOccurs="1">
+ <xs:element name="app-path" type="xs:string" minOccurs="1" maxOccurs="1"/>
+ <xs:element name="configuration" type="bundle:CONFIGURATION" minOccurs="0" maxOccurs="1"/>
+ </xs:sequence>
+ <xs:attribute name="name" type="bundle:IDENTIFIER" use="required"/>
+ <xs:attribute name="critical" type="xs:string" use="optional"/>
+ </xs:complexType>
+ <xs:complexType name="CONFIGURATION">
+ <xs:sequence>
+ <xs:element name="property" minOccurs="1" maxOccurs="unbounded">
+ <xs:complexType>
+ <xs:sequence>
+ <xs:element name="name" minOccurs="1" maxOccurs="1" type="xs:string"/>
+ <xs:element name="value" minOccurs="1" maxOccurs="1" type="xs:string"/>
+ <xs:element name="description" minOccurs="0" maxOccurs="1" type="xs:string"/>
+ </xs:sequence>
+ </xs:complexType>
+ </xs:element>
+ </xs:sequence>
+ </xs:complexType>
+</xs:schema>
+```
+
+#### Oozie Bundle Schema 0.2
+
+
+```
+<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:bundle="uri:oozie:bundle:0.2"
+ elementFormDefault="qualified" targetNamespace="uri:oozie:bundle:0.2">
+
+ <xs:element name="bundle-app" type="bundle:BUNDLE-APP"/>
+ <xs:simpleType name="IDENTIFIER">
+ <xs:restriction base="xs:string">
+ <xs:pattern value="([a-zA-Z]([\-_a-zA-Z0-9])*){1,39}"/>
+ </xs:restriction>
+ </xs:simpleType>
+ <xs:complexType name="BUNDLE-APP">
+ <xs:sequence>
+ <xs:element name="parameters" type="bundle:PARAMETERS" minOccurs="0" maxOccurs="1"/>
+ <xs:element name="controls" type="bundle:CONTROLS" minOccurs="0" maxOccurs="1"/>
+ <xs:element name="coordinator" type="bundle:COORDINATOR" minOccurs="1" maxOccurs="unbounded"/>
+ </xs:sequence>
+ <xs:attribute name="name" type="xs:string" use="required"/>
+ </xs:complexType>
+ <xs:complexType name="PARAMETERS">
+ <xs:sequence>
+ <xs:element name="property" minOccurs="1" maxOccurs="unbounded">
+ <xs:complexType>
+ <xs:sequence>
+ <xs:element name="name" minOccurs="1" maxOccurs="1" type="xs:string"/>
+ <xs:element name="value" minOccurs="0" maxOccurs="1" type="xs:string"/>
+ <xs:element name="description" minOccurs="0" maxOccurs="1" type="xs:string"/>
+ </xs:sequence>
+ </xs:complexType>
+ </xs:element>
+ </xs:sequence>
+ </xs:complexType>
+ <xs:complexType name="CONTROLS">
+ <xs:sequence minOccurs="0" maxOccurs="1">
+ <xs:element name="kick-off-time" type="xs:string" minOccurs="0" maxOccurs="1"/>
+ </xs:sequence>
+ </xs:complexType>
+ <xs:complexType name="COORDINATOR">
+ <xs:sequence minOccurs="1" maxOccurs="1">
+ <xs:element name="app-path" type="xs:string" minOccurs="1" maxOccurs="1"/>
+ <xs:element name="configuration" type="bundle:CONFIGURATION" minOccurs="0" maxOccurs="1"/>
+ </xs:sequence>
+ <xs:attribute name="name" type="bundle:IDENTIFIER" use="required"/>
+ <xs:attribute name="critical" type="xs:string" use="optional"/>
+ <xs:attribute name="enabled" type="xs:string" use="optional"/>
+ </xs:complexType>
+ <xs:complexType name="CONFIGURATION">
+ <xs:sequence>
+ <xs:element name="property" minOccurs="1" maxOccurs="unbounded">
+ <xs:complexType>
+ <xs:sequence>
+ <xs:element name="name" minOccurs="1" maxOccurs="1" type="xs:string"/>
+ <xs:element name="value" minOccurs="1" maxOccurs="1" type="xs:string"/>
+ <xs:element name="description" minOccurs="0" maxOccurs="1" type="xs:string"/>
+ </xs:sequence>
+ </xs:complexType>
+ </xs:element>
+ </xs:sequence>
+ </xs:complexType>
+</xs:schema>
+```
+
+
+[::Go back to Oozie Documentation Index::](index.html)
+
+