RAC Job Container
Contents
cla140
Contents
When a target computer reports that it has had a new operating system (OS) installation (visible by a change in the HostUUID), all old successful installation and delivery records will be marked with "*Removed by RAC" in the job history of the target computer.
If the configuration policy "DSM/software delivery/Manager/RAC" is set to False, existing records remain untouched and no RAC job container is created.
Then, depending on the current RAC policy configuration setting, a job container will automatically be created or not by a domain manager. All old successful jobs associated with the installation and delivery records previously mentioned are included in the container that will appear in the list of job containers, with its name prefixed by RAC. The name of the job container follows the scheme:
RAC:
computer_name
[ current_date
current_time
]All RAC containers are tagged with the UUID of the actual computer at the time it got the new OS installation. This ensures that only RAC containers with an up-to-date UUID will be performed. Jobs in an RAC container with an old UUID will fail and set in error state: RAC container obsolete. This situation may occur if the software delivery agent is reinstalled with a new operating system, before a previously generated RAC container has finished executing.
New installations and jobs, generated off-line and reported along with the new OS installation (that is, using the new UUID), are not included in the RAC container. Old and new installations for targets are separated, by recording the UUID for each job. All job records generated off-line are tagged with the UUID.
The restriction in previous software delivery versions to prohibit execution of activate and configure procedures, unless bound to an existing installation for the current target, has been weakened to let an RAC container carry out all jobs, based on the job history of the job target, in one attempt.
To regenerate as much as possible of the target, the default values used for an RAC job container are:
- Batch job execution
- Enable transaction is not set
- Ignore cascading install of dependent packages is not set
Batch linkage can be changed to synchronized for an unsealed job container.
When creating the RAC container, the completion time of the computer jobs (job history) is used to establish the initial order of the jobs. Deliveries are always placed first. As long as the job container is unsealed, jobs can be deleted or repositioned. More jobs can also be added to the container.
If a job cannot be set up, since the software to use is archived, the job is set in warning state and the job container is left unsealed.
Jobs that had not finished executing before RAC was initiated are set in error state. They are not included in the RAC container and cannot be renewed, since they are tagged with the old UUID. After the RAC process has finished, check whether they should be set up again.
When a RAC job container has been created for a target, the target is locked until the container has completed successfully, or has been deleted. While the target is locked, the computer name is displayed in red text in the DSM Explorer tree.
During this time, it is not possible to deliver, execute, or delete any other jobs to the target computer. Any jobs that are set up fails with the error status as "Job is not allowed: Computer locked by RAC".
During the time the target computer is locked, template jobs for the actual target are set up and added to the Exceptions folder. However, when activated they will fail if the lock still remains. Jobs requested from the enterprise manager are set to error, if activated when the target computer is locked. Installation and job records cannot be deleted during the time the target computer is locked.
In situations where an RAC container fails, the standard renew function is accessible. If a job fails because it cannot execute on the new OS installation, that job can be deleted from the RAC container, before it is renewed.
If a complete renew with a new operating system is required, the RAC container should be deleted and a new OS installation be initiated.
If the selected RAC policy states that no RAC automation shall take place or if no jobs were set up, the target computer is unlocked as soon as its installation register has been cleaned up.
Job History with Retained Job Order Data
The job order option, User parameters, is retained in computer jobs. For other options, the default values are used.
Procedure options are inherited from the procedure used. Job options are as configured by the administrator. The following Job option values are the default:
- Jobs will be triggered by Scalability Server=Yes
- Use delivery calendar=No
There are two parameters, JobTimeout, and StoreInSSLibrary, in the RAC section of the configuration store that can also be used to control job timeout and whether packages should be stored in the library.
Included or Omitted Jobs in a RAC Job Container
Jobs are always included in a RAC job container, if they involve the following:
- Detected software, if the software has been converted to a real software item (registered), and has a default install procedure.
- Delivery records for a scalability server.
The following jobs are omitted from a RAC job container:
- Jobs referring to uninstalled software and procedures marked with Exclude from RAC.
- Jobs set up by an activation or configuration procedure, if their associated installation procedure is marked with Exclude from RAC.
Relation to Move Operation
Information about the relation between RAC and move operations can be found under "Moving and Reinstalling After Crash".