vania-janet/multiturn-rag-retrieval-data huggingface dataset:
The following example shows how to delete a resource reclamation with ID d9fendfwlw:

ibmcloud resource reclamation-delete "d9fendfwlw"

The following example shows how to delete a resource reclamation with ID d9fendfwlw and leave a comment of no longer needed without confirmation:

ibmcloud resource reclamation-delete "d9fendfwlw" --comment "no longer needed" -f





 Deleting resource by using the API 

To reclaim (provisionally delete) a resource, call the [IBM Cloud® Resource Controller API](https://cloud.ibm.com/apidocs/resource-controller/resource-controller?code=gorun-reclamation-action) as shown in the following example. Specify reclaim to delete a resource. id is the reclamation ID and not the resource instance ID.



* Curl
* Java
* Python
* Go
* Node



curl -X POST https://resource-controller.cloud.ibm.com/v1/reclamations/0114be9024c6eede47d08a85ac0c5c43/actions/reclaim -H 'Authorization: Bearer <IAM_TOKEN>' -H 'Content-Type: application/json' -d '{
"request_by": "bar",
"comment": "reclaim resource instance 614fc866-1d4f-4c9e-973e-637f1089a6a1"
}'

RunReclamationActionOptions runReclamationActionOptions = new RunReclamationActionOptions.Builder()
.id(reclamationId)
.actionName("reclaim")
.build();

Response<Reclamation> response = service.runReclamationAction(runReclamationActionOptions).execute();
Reclamation reclamation = response.getResult();

System.out.printf("runReclamationAction() response:n%sn", reclamation.toString());

reclamation = resource_controller_service.run_reclamation_action(
+ resource "ibm_resource_instance" "terraform_demo" {
+ account_id = (known after apply)
+ allow_cleanup = (known after apply)
+ created_at = (known after apply)
+ created_by = (known after apply)
+ crn = (known after apply)
+ dashboard_url = (known after apply)
+ deleted_at = (known after apply)
+ deleted_by = (known after apply)
+ extensions = (known after apply)
+ guid = (known after apply)
+ id = (known after apply)
+ last_operation = (known after apply)
+ location = "us-south"
+ locked = (known after apply)
+ name = "terraform_demo"
+ plan = "lite"
+ plan_history = (known after apply)
+ resource_aliases_url = (known after apply)
+ resource_bindings_url = (known after apply)
+ resource_controller_url = (known after apply)
+ resource_crn = (known after apply)
+ resource_group_crn = (known after apply)
+ resource_group_id = (known after apply)
+ resource_group_name = (known after apply)
+ resource_id = (known after apply)
+ resource_keys_url = (known after apply)
+ resource_name = (known after apply)
+ resource_plan_id = (known after apply)
+ resource_status = (known after apply)
+ restored_at = (known after apply)
+ restored_by = (known after apply)
+ scheduled_reclaim_at = (known after apply)
+ scheduled_reclaim_by = (known after apply)
+ service = "event-notifications"
+ service_endpoints = (known after apply)
+ state = (known after apply)
+ status = (known after apply)
+ sub_type = (known after apply)
+ tags = (known after apply)
+ target_crn = (known after apply)
However, the service must preserve the operation result for a reasonable amount of time, for example 24 hours, to allow the client time to consume it.





 Cancellation 

Services MAY support operation cancellation by exposing DELETE on the operation. If supported, DELETE operations MUST be idempotent. Operations that support cancellation MUST sufficiently describe their cancellation such that the state of the system can be accurately determined, and any compensating actions may be run.







 Resource-based long-running operations 

Any resource that could be the subject of a long-running operation MUST have a status field and this field SHOULD be named status. The status field SHOULD be defined as an enumeration and all potentially long-running operations MUST clearly describe how the completion of the operation is signaled with the value stored in the status field.





 Retry-After 

Long-running operations SHOULD return a Retry-After header in the original response that contains the number of seconds that the client should wait before trying to get the status of the operation, to avoid excessive polling. A Retry-After header MAY also be included in the response to GET requests on an operation resource.
* <MARKER> - The bucket name to start the listing (Skip until this bucket).
* <PREFIX - Only include buckets whose name start with this prefix.







 Archive Tier Support 

You can automatically archive objects after a specified length of time or after a specified date. Once archived, a temporary copy of an object can be restored for access as needed. Please note the time required to restore the temporary copy of the object(s) may take up to 12 hours.

To use the example provided, provide your own configuration—including replacing <apikey> and other bracketed <...> information—keeping in mind that using environment variables are more secure, and one should not put credentials in code that will be versioned.

An archive policy is set at the bucket level by calling the PutBucketLifecycleConfiguration method on a client instance. A newly added or modified archive policy applies to new objects uploaded and does not affect existing objects.

func main() {

// Create Client
sess := session.Must(session.NewSession())
client := s3.New(sess, conf)

// PUT BUCKET LIFECYCLE CONFIGURATION
// Replace <BUCKET_NAME> with the name of the bucket
lInput := &s3.PutBucketLifecycleConfigurationInput{
Bucket: aws.String("<BUCKET_NAME>"),
LifecycleConfiguration: &s3.LifecycleConfiguration{
Rules: []s3.LifecycleRule{
{
Status: aws.String("Enabled"),
Filter: &s3.LifecycleRuleFilter{},
ID: aws.String("id3"),
Transitions: []s3.Transition{
{
Days: aws.Int64(5),
StorageClass: aws.String("Glacier"),
},
},
},
},
},
}
l, e := client.PutBucketLifecycleConfiguration(lInput)
fmt.Println(l) // should print an empty bracket
Name (required)
: Name of the service instance, exclusive with ID

ID (required)
: ID of the service instance, exclusive with NAME

-f, --force
: Force deletion without confirmation

--recursive
: Delete all belonging resources





 Examples 

Delete resource service-instance my-service-instance:

ibmcloud resource service-instance-delete my-service-instance







 ibmcloud resource service-instance-lock 

Lock service instance.

ibmcloud resource service-instance-lock ( NAME | ID ) [-g RESOURCE_GROUP] [-f, --force]



 Command options 

Name (required)
: Name of the service instance, exclusive with ID

ID (required)
: ID of the service instance, exclusive with NAME

-g RESOURCE_GROUP
: Resource group name

-f, --force
: Force locking without confirmation





 Examples 

Lock resource service-instance my-service-instance:

ibmcloud resource service-instance-lock my-service-instance







 ibmcloud resource service-instance-unlock 

Unlock service instance.

ibmcloud resource service-instance-unlock ( NAME | ID ) [-g RESOURCE_GROUP] [-f, --force]



 Command options 

Name (required)
: Name of the service instance, exclusive with ID

ID (required)
: ID of the service instance, exclusive with NAME

-g RESOURCE_GROUP
: Resource group name

-f, --force
: Force locking without confirmation





 Examples 

Unlock resource service-instance my-service-instance:

ibmcloud resource service-instance-unlock my-service-instance







 ibmcloud resource service-bindings 

Show bindings to the service alias.

ibmcloud resource service-bindings SERVICE_ALIAS



 Command options 

SERVICE_ALIAS (required)
: Service alias name





 Examples 

Show resource bindings to service alias my-service-alias:

ibmcloud resource bindings my-service-alias







 ibmcloud resource service-binding 

Show details of a service binding.
If you need to adjust resources or use a Key Protect key, add the optional parameters key_protect_key, members_disk_allocation_mb, members_memory_allocation_mb, and/or members_cpu_allocation_count, and their values to the body of the request.





 Restoring a backup with Terraform 

Before restoring, ensure that your point_in_time_recovery_time is no older than one week. If the timestamp is any older than 7 days, down to the second, validation fails.

Use the [ibm_database_point_in_time_recovery](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/data-sources/database_pitr) data source to restore your database instance with [point_in_time_recovery](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/databasesample-database-instance-by-using-point_in_time_recovery).

The point-in-time-recovery timestamp must be formatted as follows: %Y-%m-%dT%H:%M:%SZ.

Your Terraform script looks like this.

terraform {
required_providers {
ibm = {
version = "1.44.3"
source = "IBM-Cloud/ibm"
}
}
}

variable "ibmcloud_api_key" {
description = "<Enter your IBM Cloud API Key>"
}

provider "ibm" {
region = "us-south"
ibmcloud_api_key = var.ibmcloud_api_key
}

data "ibm_resource_group" "default_group" {
is_default = true
}

resource "ibm_database" "mongodb_enterprise" {
resource_group_id = data.ibm_resource_group.default_group.id
name = "testing-mongodb-pitr"
service = "databases-for-mongodb"
plan = "enterprise"
location = "us-south"
Regardless of whether a link is created by the system or manually by using the IAM Identity service, it automatically deletes when the instance is deleted. One of: true,false. (default: true).
* --metadata-service, --ms: Enable or disable the Instance Metadata Service. One of: true, false.
* --metadata-service-protocol, --msp: The communication protocol for the metadata service endpoint. Applies only when the metadata service is enabled. One of: http, https. (default: http).
* --metadata-service-response-hop-limit, --msrhl: The hop limit (IP time to live) for IP response packets from the metadata service.
* --host-failure-policy: The action to perform if the compute host experiences a failure. One of: restart, stop. (default: restart).
* --resource-group-id: ID of the resource group. This ID is mutually exclusive with --resource-group-name.
* --resource-group-name: Name of the resource group. This name is mutually exclusive with --resource-group-id.
* --output: Specify output format, only JSON is supported. One of: JSON.
* --interactive, -i:
* -q, --quiet: Suppress verbose output.



--------------------







 ibmcloud is instance-create-from-template 

Create a virtual server instance from instance template.
The previous dates and times are replaced with the new dates and times.







 Removing previously scheduled image from volume lifecycle statuses by using the API 

Make a PATCH /images request to remove any scheduled status change by updating deprecation_at or obsolescence_at to null. This property change removes the date and time from the image and the image is no longer scheduled for that status change.



* To change an image from deprecated to available, change the deprecation_at property to null.

curl -X PATCH "$vpc_api_endpoint/v1/images/$image_id?version=2022-11-21&generation=2" -H "Authorization: Bearer $iam_token" -d '{ "deprecation_at": null }'
* To change an image from obsolete to its previous state, change obsolescence_at to null. If the image previously contained a value other than null for deprecation_at, then this property change removes the obsolete state and changes it back to deprecated. If the previous state was available, meaning the image was moved from available directly to obsolete, then this property change moves from obsolete back to available.

curl -X PATCH "$vpc_api_endpoint/v1/images/$image_id?version=2022-11-21&generation=2" -H "Authorization: Bearer $iam_token" -d '{ “obsolescence_at": null }'
* To change an image that has both the deprecation_at or obsolescence_at properties set back to available, you must update both the deprecation_at or obsolescence_at properties.

curl -X PATCH "$vpc_api_endpoint/v1/images/$image_id?version=2022-11-21&generation=2" -H "Authorization: Bearer $iam_token" -d '{ "deprecation_at": null, “obsolescence_at": null }'







 Performance considerations 

Several factors can impact how quickly your image from volume is queued and created, such as size of the image and number of jobs in the queue.
"id": "c36e9f3a-feaf-4033-8603-687784dc7e51",
"name": "my-root-key",
"type": "application/vnd.ibm.kms.key+json",
"algorithmType": "AES",
"createdBy": "user id ...<redacted>...",
"creationDate": "2020-05-10T17:56:37Z",
"lastUpdateDate": "2020-05-10T17:56:37Z",
"extractable": false,
"state": 1,
"crn": "crn:v1:bluemix:public:kms:us-south:a/ea998d3389c3473aa0987652b46fb146:390086ac-76fa-4094-8cf3-c0829bd69526:key:c36e9f3a-feaf-4033-8603-687784dc7e51"
}
] ! !
<-- </section "id="section-kp-keys-example-3" "> --><-- <section "id="section-kp-keys-example-4" "> --> Example 4 List all keys and iterate over them, showing details. list all keys and convert to a list
$ KEYS=$(ibmcloud kp keys --output json | jq -r '.] ! ! | .id')

$ for key in $(echo "${KEYS}"); do
ibmcloud kp key show ${key}
done

Grabbing info for key id: 5f2cc155-fe16-492c-845c-4d1f0688c7ba...
OK
Key ID Key Name Description Creation Date Expiration Date
DEBUG:urllib3.connectionpool:https://us.schematics.cloud.ibm.com:443 "PUT /v1/workspaces/us-south.workspace.Schematic-Sunil-Test-Workspace.5a4cbf11/destroy HTTP/1.1" 202 49
{
  "activityid": "4bc90aac48f7cf9850bddf1ba9407eb5"
}
INFO:root:Completed Deletion of Schematic Resources
Customers with special requirements for compliance such as NIST 800-88 Guidelines for Media Sanitization can perform the data sanitization procedure before they delete their storage.
* What happens to the drives that are decommissioned from the cloud data center?

When drives are decommissioned, IBM destroys them before they are disposed of. The drives become unusable. Any data that was written to that drive becomes inaccessible.
* I cannot cancel a Block Storage for Classic volume because the Cancel action in the Cloud console is disabled. What’s happening?

The cancellation process for this storage device is in progress so the Cancel action is no longer available. The volume remains visible for at least 24 hours until it is reclaimed. An hourglass or clock icon appears next to the device name to indicate that it’s in a waiting period. The minimum 24-hour waiting period gives you a chance to void the cancel request if needed.
* My Windows® 2012 host is supposed to have access to multiple Storage LUNs, but I can't see them in Disk Manager. How do I fix it?

If you use more than two iSCSI LUNs with the same host, and if all the iSCSI connections are from the same Storage device, you might find that you can see only two devices in Disk Manager. When this situation happens, you need to manually connect to each device in the iSCSI Initiator. For more information, see [troubleshooting Windows® 2012 R2 - multiple iSCSI devices](https://cloud.ibm.com/docs/BlockStorage?topic=BlockStorage-troubleshootingWin12).
* My storage appears offline or read-only. Why did it happen and how do I fix it?

In a couple of scenarios a host (bare metal or VM) might lose connection to the storage briefly and as a result, the host considers that storage read-only to avoid data corruption. Most of the time the loss of connectivity is network-related but the status of the storage remains read-only from the host's perspective even when the network connection is restored. A restart of the host solves the read-only state issue.

This issue can be observed with hosts that have incorrect MPIO settings.
This value is optional. The default value is false.

--wait, -w
: Delete the project and wait for the project to be deleted. If you specify the --wait option, the project delete waits for a maximum time in seconds, as set by the --wait-timeout option, for the project to become deleted. If the project is not deleted within the specified --wait-timeout period, the project delete fails. This value is optional. The default value is true.

--wait-timeout, --wto
: The length of time in seconds to wait for the project to be deleted. This value is required if the --wait option is specified. This value is ignored if the --no-wait option is specified. The default value is 600.





 Example 

ibmcloud ce project delete --name myproject -f





 Example output 

Deleting project 'myproject'...
OK







 ibmcloud ce project get 

Display the details of a single project.

ibmcloud ce project get (--name PROJECT_NAME | --id PROJECT_ID) [--output OUTPUT] [--quiet]



 Command Options 

--id, --guid
: The ID of the project. This value is required if --name is not specified.

--name, -n
: The name of the project. This value is required if --id is not specified.

--output, -o
: Specifies the format of the command output. Valid values are json, yaml, jsonpath=JSONPATH_EXPRESSION, and jsonpath-as-json=JSONPATH_EXPRESSION. Use jsonpath to specify the path to an element of the JSON output. This value is optional.

--quiet, -q
: Specify this option to reduce the output of the command. This value is optional. The default value is false.





 Example 

ibmcloud ce project get --name myproject





 Example output 

Getting project 'myproject'...
OK
To remove a scheduled status change, see [Remove a scheduled custom image lifecycle status change by using the CLI](https://cloud.ibm.com/docs/vpc?topic=vpc-image-from-volume-vpc-manageschedule-reset-ilm-status-change-cli). After you remove the scheduled status change, you can make an immediate status change.



* Change the image lifecycle status to deprecate.

ibmcloud is image-deprecate IMAGE
* Change the image lifecycle status to obsolete.

ibmcloud is image-obsolete IMAGE



To schedule a status change, use the following example.

For the deprecate-at or obsolete-at option, specify a date in the ISO 8601 (YYYY-MM-DDThh:mm:ss+hh:mm) date and time format.



* YYYY is the four digit year
* MM is the two digit month
* DD is the two digit day
* T separates the date and time information
* hh is the two digit hours
* mm is the two digit minutes
* +hh:mm or -hh:mm is the UTC time zone



Thus, the date of 30 September 2023 at 8:00 p.m. in the North American Central Standard Time Zone (CST) would be 2023-09-30T20:00:00-06:00

When scheduling the date and time, you can't use your current date and time. For example, if it is 8 a.m. on June 12, then the scheduled date and time must be after 8 a.m. on June 12. If you define both the deprecate-at and obsolete-at dates, the obsolete-at date must be after the deprecate-at date.

ibmcloud is image-update IMAGE [--deprecate-at YYYY-MM-DDThh:mm:ss+hh:mm] [--obsolete-at YYYY-MM-DDThh:mm:ss+hh:mm]

If you want to change the deprecate-at and obsolete-at date and time entries, you can run these commands again.
ibmcloud cr namespace-assign -g <my_resource_group> <my_namespace>







 Removing namespaces 

If you no longer require a registry namespace, you can remove the namespace from your IBM Cloud account.



1. Log in to IBM Cloud.

ibmcloud login
2. List available namespaces.

ibmcloud cr namespace-list
3. Remove a namespace.

When you remove a namespace, any images that are stored in that namespace are also deleted. This action cannot be undone.

Replace <my_namespace> with the namespace that you want to remove.

ibmcloud cr namespace-rm <my_namespace>

After you delete a namespace, it might take a few minutes before that namespace becomes available again to reuse.
* You minimize the chances of accidentally removing an image that might be in use in your staging or production environments, when compared with using a single namespace for all images.
* You can use different [IAM](https://cloud.ibm.com/docs/Registry?topic=Registry-iam) policies. For example, you can have more restrictive access to production images.
* You can sign production images, but leave development and staging images unsigned.







 Clean up your namespaces to keep a set number of images 

Use the ibmcloud cr retention-run command to clean up a namespace by retaining a specified number of images for each repository within a namespace in IBM Cloud Container Registry. All other images in the namespace are deleted.

You can choose whether to exclude untagged images from the clean-up process.

The [ibmcloud cr retention-run](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_retention_run) command lists the images to delete and gives you the option to cancel before deletion.

Where an image, within a repository, is referenced by multiple tags, that image is counted only once. Newest images are retained. Age is determined by when the image was created, not when it was pushed to the registry.

If you want to restore a deleted image, you can list the contents of the trash by running the [ibmcloud cr trash-list](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_trash_list) command and restore a selected image by running the [ibmcloud cr image-restore](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_restore) command.

To reduce the number of images in each repository within your namespace by using the CLI, complete the following steps:



1. Log in to IBM Cloud by running the ibmcloud login command.
2. Choose the registry in which you want to clean up your images by running the following command and selecting the appropriate region:

ibmcloud cr region-set
3.
2020/01/10 21:27:50 Terraform plan | provisioning_status: "active" => <computed>
2020/01/10 21:27:50 Terraform plan | target_address: "172.16.2.4" => "172.16.2.4"
2020/01/10 21:27:50 Terraform plan | weight: "50" => <computed>
2020/01/10 21:27:50 Terraform plan | Plan: 3 to add, 0 to change, 2 to destroy.
2020/01/10 21:27:50 Command finished successfully.
7. Optional: Apply the changes in your cloud environment by clicking Apply plan.







 Removing your resources 

To remove an IBM Cloud resource that you provisioned with IBM Cloud Schematics, you can either remove your resources with Schematics, delete your workspace, or remove the infrastructure code in the Terraform template.

How should I remove resources with IBM Cloud Schematics?
You can use the IBM Cloud Schematics console or command-line to remove all the resources that you provisioned with Schematics. To stay in sync with your Terraform template, make sure to also remove the associated infrastructure code from your Terraform template so that your resources are not re-added when you apply a new version of your Terraform template.

What happens if I choose to delete my resource directly from the resource dashboard?
When you manually remove a resource that you provisioned with IBM Cloud Schematics, the state file is not updated automatically and becomes out of sync. When you create your next Terraform execution plan or apply a new template version, Schematics verifies that the IBM Cloud resources in the state file exist in your IBM Cloud account with the state that is captured. If the resource is not found, the state file is updated and the Terraform execution plan is changed accordingly.

Although the state file is updated before new changes to your IBM Cloud resources are applied, do not manually remove resources from the resource dashboard to avoid unexpected results. Instead, use the IBM Cloud Schematics console or command-line to remove your resources, or remove the associated infrastructure code from your Terraform template.

Are my resources removed when I remove the workspace