Specifying job options
Job options let you customize the behavior of a Deploy Job.
To specify job options
- To set the logging level for the job, select one of the following options from Logging Level:
- Errors only — Only errors are displayed and output to a log.
- Errors and warnings — Errors and warnings are displayed and output to a log.
- All information — All messages, including errors and warnings, are displayed and output to a log.
- If you are defining an advanced BLPackage Deploy Job, take the following steps:
- Under Flow Control, select one of the following options:
- By server — The job proceeds as far as it can for each server. When one server fails, the job continues on other servers. When the job completes a phase on one server, the job continues to the next phase on that server. This option is useful when you want the job to complete on as many servers as possible. A failure on one server does not impede the job on other servers.
- By phase — The job completes a phase on all servers before it proceeds to the next phase. This option is useful when you want a deployment to be completely successful, such as when you are updating a web application.
- If you selected By phase in the previous step, you can optionally check All hosts must pass commit, which instructs the job to undo the Commit phase to all targets if any targets do not successfully complete the Commit phase.
If you check this option and a job fails, the system undoes the staging phase of the Deploy Job. - Check Reset job on failure to allow this job to be run again even though the job failed at least one phase on at least one server.
Checking this option places failed jobs into a Reset state. Unless you check this option, a job cannot be run again until it completes successfully.
- Under Flow Control, select one of the following options:
- Under Parallel Job Options, do any of the following:
Select Enable single-job mode if this Deploy Job should not run in parallel on a target with any other Deploy Jobs.
A job in single-job mode can only run when the target server is not currently processing other Deploy Jobs. If another Deploy Job is running, this Deploy Job waits until the other job is complete. While this job is being processed on a target server, no other Deploy Job can run.
If you are deploying a package that includes an item that requires single-user mode or a reboot, the job must be processed in single-job mode. In this situation, the Enable single-job mode option is automatically checked and you cannot clear it.- Select Fail job if waiting in Agent deploy queue... and then enter a maximum wait in minutes in the field at right.
Agents queue Deploy Jobs that are waiting to process. If this Deploy Job does not run before the specified period of time has elapsed, the job fails. If you do not check this option or you do check this option and enter a 0 as a maximum wait time, the job waits to run indefinitely.
If the Deploy Job fails when the Application Server loses contact with a target server, check Fail job if any Agent connection loss exceeds... (This option appears under Agent Connection Timeout.) Then, in the field to the right, enter a maximum period of time in minutes that the job can wait to regain contact with the agent before the job fails. If you do not check this option or you do check this option and enter a 0 as a maximum wait time, the job waits to run indefinitely.
Under User Mode Options (UNIX Only), select one of the following from the drop-down list:
Option
Description
Use item defined user mode setting
When processing each object being deployed, this Deploy Job uses the user mode setting (single- or multi-user) defined for that object.
Ignore item defined user mode setting
Prevents a server from entering single-user mode no matter how individual objects in the package are defined.
Use single-user mode without reboot
This Deploy Job is processed on a target server using single-user mode. The job switches into single-user mode without first rebooting or shutting down.
Reboot into single-user mode
This Deploy Job reboots or shuts down a target server so the server enters single user mode. The job is then processed using single-user mode.
Under Reboot Options, select one of the following from the drop-down list:
Option
Description
Use item defined reboot setting
Causes a target to reboot after an object in the BLPackage is processed if the instructions for that object call for a reboot. If the reboot setting for an object is By end of job and a reboot is not scheduled for this job, then a reboot occurs at the end of the job.
Ignore item defined reboot setting
Prevents a server from rebooting no matter how a package is defined unless the object being deployed includes an out-of-band reboot (that is, a reboot that is built into the object and is not part of the BLPackage instructions).
Use item defined reboot setting and reboot at end of job
Causes a target to reboot after each object in the BLPackage is processed if the instructions for that object call for a reboot. In addition, at the end of the job a final reboot occurs if the last item in the job is not defined to reboot. If the last item is defined to reboot, only one final reboot occurs at the end of the job.
Ignore item defined reboot setting and reboot at end of job
Prevents a server from rebooting during a job no matter how a package is defined unless the object being deployed includes an out-of-band reboot (that is, a reboot is built into the object and is not part of the BLPackage instructions). At the end of the job, the server reboots.
Consolidate any "After item deployment" reboots until end of job
Prevents a server from rebooting unless the item being deployed includes an out-of-band reboot (that is, a reboot that is built into the object and is not part of the BLPackage instructions). If any job items are defined to reboot after deployment, those reboots are consolidated into one reboot at the end of the job. If no job items require a reboot, no reboot occurs at the end of job. If a deployment to Solaris target servers includes items that require a reconfiguration reboot, those reboot requests are consolidated and the reboot at the end of the job is a reconfiguration reboot.
- New in 20.02(For Windows servers) If the target servers require a reboot before patching, select the Reboot before commit if server is pending reboot (Windows only) check box. The deploy job automatically reboots the target servers before the commit phase. If you do not select this check box, the deploy job fails on the target servers for which reboot is pending.
- For Solaris target servers, specify how the job should handle reconfiguration reboots by doing the following:
- If any end-of-job reboots are specified in the previous step, indicate whether those reboots should be reconfiguration reboots by checking Use configuration reboot for reboot "at end of job"...
Specify how the Deploy Job should manage item-level reconfiguration reboots by selecting one of the following:
Option
Description
Use item defined reconfigure setting
Instructs the Deploy Job to use the reconfiguration reboot settings defined for objects being deployed. These reboots occur in addition to the end-of-job reconfiguration reboot setting specified in step 7.a
Ignore item defined reconfigure setting
Instructs the Deploy Job to ignore any reconfiguration reboot settings defined for objects being deployed, regardless of whether you specified an end-of-job reconfiguration reboot in step a. If you choose this option, only the reconfiguration aspect of the reboot is ignored. If an item definition calls for a reconfiguration reboot, a reboot still occurs but it is not a reconfiguration reboot.
For a complete description of the interactions between reboot settings, see Interactions-between-reboot-settings.