Many of the operations that you can perform in the Compute service do not take effect immediately. For example, when you create an instance, it might take several minutes for the instance to transition from the provisioning state to running. When you launch a long-running operation, the Compute service spawns a work request. A work request is an activity log that enables you to track each step in the operation's progress.
If an operation fails, a work request can help you determine which step of the process had an error.
Some operations affect multiple resources. For example, creating an instance pool also affects instances and instance configurations. A work request provides a list of the resources that an operation affects.
For workflows that require sequential operations, you can monitor each operation’s work request and confirm that the operation has completed before proceeding to the next operation. For example, say that you want to create an instance pool with autoscaling enabled. To do this, you must first create the instance pool, and then configure autoscaling. You can monitor the work request for creating the instance pool to determine when that workflow is complete, and then configure autoscaling after it is done.
Work requests are retained for 12 hours.
To use Oracle Cloud Infrastructure, you must be given the required type of access in a An IAM document that specifies who has what type of access to your resources. It is used in different ways: to mean an individual statement written in the policy language; to mean a collection of statements in a single, named "policy" document (which has an Oracle Cloud ID (OCID) assigned to it); and to mean the overall body of policies your organization uses to control access to resources. written by an administrator, whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you try to perform an action and get a message that you don’t have permission or are unauthorized, confirm with your administrator the type of access you've been granted and which A collection of related resources that can be accessed only by certain groups that have been given permission by an administrator in your organization. you should work in.
For administrators: Work requests inherit the permissions of the operation that spawns the work request. To enable users to view the work requests, logs, and error messages for an operation, write a policy that grants users permission to do the operation. For example, to let users see the work requests associated with launching instances, write a policy that enables users to launch instances.
To enable users to list all work requests in a tenancy, use the following policy:
Allow group SupportTeam to inspect work-requests in tenancy
Operations that Generate Work Requests
These long-running operations spawn work requests:
- Creating an instance
- Creating a custom image
- Importing or exporting an image
- Creating an instance pool
- Updating an instance pool
- Deleting an instance pool
- Moving an instance to a different compartment
Work Request States
The work request statuses are:
- The request is in the work request queue to be processed.
- A work request record exists for the specified request, but there is no associated WORK_COMPLETED record.
- A work request record exists for this request and an associated WORK_COMPLETED record has the state SUCCEEDED.
- A work request record exists for this request and an associated WORK_COMPLETED record has the state FAILED.
- The work request is in the process of canceling.
- The work request has been canceled.
|InternalError||Instance launch failed. Try again later.|
|InternalError||Out of host capacity. Try again later, or try in a different fault domain or availability domain.|
|1600||Failed to launch instances for instance pool.|
|1600||Instance launch failed.|
|1602||Total number of instance launch failures: <number>.|
|1603||Failed to terminate instances for instance pool.|
|1603||Failed to terminate instance.|
|1604||Action on instance failed.|
|1604||Failed to perform action on instance in instance pool.|
|1605||Failed to create backends because the load balancer was not found. Verify that the load balancer exists. See Overview of Load Balancing.|
|1605||Failed to create backends for instances in pool.|
|1605||Failed to create load balancer backend for instance.|
|1605||Failed work request to create load balancer attachment.|
|1605||Failed to process request to create load balancer attachment.|
|1606||Failed to delete load balancer backend on backend set for load balancer.|
|1606||Failed work request to remove load balancer attachment. View the dependent work request for more information.|
|1606||Failed to process request to remove load balancer attachment.|
|1606||Failed to drain load balancer backend on backend set for load balancer.|
Using the Console
The steps to view a work request are similar for the various Compute operations.
Navigate to resource whose work requests you want to see.
For example, to see the work requests for a Compute instance: Open the navigation menu. Under Core Infrastructure, go to Compute and click Instances.
- Click the resource's name.
- In the Resources section, click Work Requests. The status of all work requests appears on the page.
To see the log messages, error messages, and resources that are associated with a specific work request, click the operation name. Then, select an option in the More information section.
For associated resources, you can click the the Actions icon (three dots) next to a resource to copy the resource's OCID.
Using the API
For information about using the API and signing requests, see REST APIs and Security Credentials. For information about SDKs, see Software Development Kits and Command Line Interface.
Use these API operations to monitor the state of work requests: