Understanding Jobs

A job is an action that Autonomous Linux takes against one or more instances, such as installing updates or attaching software sources. When a job runs, a work request is created that performs the tasks necessary to fulfill the job, dispatches work to instances, and reports the results back to the service.

A job can run immediately or you can set it to run at a future date and time, or as a recurring event. This is a scheduled job. You can elect to automatically retry a scheduled job in the event of failure. When automatic retry is selected, if the scheduled job fails on its first execution, the service retries the scheduled job up to three times, each five minutes apart. Scheduled jobs can also be tagged.

Scheduled Job State

Scheduled jobs are in one of the following states:

Next execution: The date and time when the job is scheduled to run.
Frequency: Indicates if the job is set to run on a recurring schedule or if it only runs once.
Targets: Identifies the number of target instances for the job.

Work Request Status

After being dispatched as a work request, a job is either in progress or completed.

In progress work requests report the following possible status values:
- Accepted: The service has accepted the job and has work ready for instances. If a job isn't picked up by an agent and remains in the accepted state for 24 hours, the service marks the job as failed.
- In Progress: An agent has picked up the accepted work and is executing it on an instance.
- Canceling: The job is being canceled.
Completed work requests report the following possible status values:
- Successful: The job completed without error.
- Failed: The job failed.
- Canceled: The job was canceled.

You can view the detailed results of a job by viewing the job log and error messages. When a job has a hierarchy, if any child job fails, the service marks the parent job as failed.

Rerunning a Failed Job

If a job fails, you can rerun the failed job instead of manually creating a new job to retry the failed action. You can rerun a failed job immediately or schedule it to run at a future date and time. Rerunning the job creates a new work request for the same action (such as applying updates or attaching software sources). The original job and its status remain unchanged for auditing and historical purposes.

For jobs in a hierarchy, you can rerun the parent job to rerun all the jobs in the hierarchy, or rerun child jobs individually. When you rerun a failed parent, the service only targets the failed children jobs. For example, suppose you have a group of ten instances and an update job fails on three of the instances. After reviewing the job log and error messages and addressing the issues reported, you can rerun the failed job for the group. The rerun targets only the three instances that experienced the original failure.

Restricted Scheduled Job

Each instance in Autonomous Linux has a restricted scheduled job with update type 'All' that runs daily to keep the instance up-to-date. This is referred to as the autonomous updates job. You can edit the time of day that the job runs, but can't change its frequency or delete the job.

Job Hierarchy

Some jobs are divided into smaller tasks. The service creates a job hierarchy where the initial job is the 'parent' and the smaller tasks are 'children'. For larger jobs, or jobs that affect several instances, you can easily work out what tasks within a job succeeded or failed. You can view children jobs in the Work requests tab in the parent job's detail page.

For example, an 'All' update job creates children jobs for each update type: Security, Bug fix, Enhancement, Other.

--Update All (parent)
  |--Update Security    (child)
  |--Update Bug fix     (child)
  |--Update Enhancement (child)
  |--Update Other       (child)

A job resides in the same compartment as its associated resource. For jobs associated with a group, this can mean the parent and children jobs are in different compartments. The parent job resides in the compartment associated with the group, while the children jobs reside in the compartment associated with each instance. See Compartment Considerations for best practices.

For example, adding a software source to a group with three members produces a single parent job with three children jobs, one for each instance.

--Set software sources for dev group (parent in dev compartment)
  |--Set software source Instance 1 (child in dev compartment)
  |--Set software source Instance 2 (child in test compartment)
  |--Set software source Instance 3 (child in preview compartment)