vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Completing workload operator actions through a bastion host 

All interactive operator actions on the resources in Satellite location must be run through a bastion host in the management plane. A bastion host is a server that can be accessed through SSH, Windows Remote Desktop Protocol (RDP), oc (Red Hat OpenShift CLI), or kubectl, but only through a private secure connection. After set up, the bastion host allows a secure connection to Red Hat OpenShift on IBM Cloud clusters, Satellite APIs, or Satellite location hosts. Administrative tasks on the individual services or hosts are completed by using SSH, oc, or kubectl proxied through the bastion. In addition, session auditing must be enabled to record all privileged user actions.

After connecting to your management plane through your designated connection method specific to your environment, a complete bastion solution should meet the following requirements.



* Full session recording of actions executed via the bastion to perform session audits. This includes SSH, and Kubernetes exec (kubectl exec -it) sessions.



* Linux-based session recordings are captured as a raw dump of stdout and stderr streams, including TAB characters (bash escape sequences).
* Session recordings should be placed in to a storage service maintained within your environment for archiving. The storage should be configured as “immutable object storage.” Retention policies are should be applied to the storage, so that data is stored in a WORM (Write-Once-Read-Many), non-erasable and non-rewritable manner. The policy is set and enforced for a 12-month (minimum) retention period.



* Authenticating users with MFA using a physical hardware-based security key that generates a six-digit numerical code. A smart card or hardware token designed and operated to FIPS 140-2 level 2 or above or equivalent (e.g., ANSI X9.24, ISO 13491-1:2007) is recommended.
* Locking user accounts after three (3) consecutive failed logon attempts within 15 minutes.
* Locking user accounts for 30 minutes when there have been more than three unsuccessful logon attempts. After the lockout period ends, the user will be able to reset their password.
.catch((e) => {
console.log(ERROR: ${e.code} - ${e.message}n);
});
}





 List legal holds on a protected object 

This operation returns:



* Object creation date
* Object retention period in seconds
* Calculated retention expiration date based on the period and creation date
* List of legal holds
* Legal hold identifier
* Timestamp when legal hold was applied



If there are no legal holds on the object, an empty LegalHoldSet is returned. If there is no retention period specified on the object, a 404 error is returned.

function listLegalHoldsOnObject(bucketName, objectName) {
console.log(List all legal holds on object ${objectName} in bucket ${bucketName});
return cos.listLegalHolds({
Bucket: bucketName,
Key: objectId
}).promise()
.then((data) => {
console.log(Legal holds on bucket ${bucketName}: ${data});
})
.catch((e) => {
console.log(ERROR: ${e.code} - ${e.message}n);
});
}





 Create a hosted static website 

This operation requires permissions, as only the bucket owner is typically permitted to configure a bucket to host a static website. The parameters determine the default suffix for visitors to the site as well as an optional error document.

var websiteParams = {
Bucket: "bucketName",
WebsiteConfiguration: {
ErrorDocument: {
Key: "error.html"
},
IndexDocument: {
Suffix: "index.html"
}
}
};
function putBucketWebsiteConfiguration(websiteParams) {
return cos.putBucketWebsite({websiteParams}).promise()
.then((data) => {
console.log(Website configured for ${bucketName});
"pipeline_run_id": "f333b3bc-3333-3fea-3333-333d3a3b33b3",
"pipeline_id": "444aaa4a-b4c4-4444-4f4b-aa4444a444a4"
},
"details": {
"result": "success"
},
"issues": [],
"attachments": {
"app-image_signature": "0000000011111111222222223333333344444444555555556666666677777777"
},
"assets": [
"docker://us.icr.io/foo/bar:v1.2.3@sha256:0000000011111111222222223333333344444444555555556666666677777777"
]
}
Show more





 cocoa locker evidence summary < asset-id > 

Returns the evidence summary for one or more assets. When no assets are specified on the command line, assets are read from stdin.

Optional flags:



* --latest-only: Discards evidence if newer evidence is available for an asset (true by default, set to false to disable this behavior)
* --scope: Considers evidence that has the specified scope only (see evidence add --scope), can be specified multiple times
* --check-immutable-storage: Checks if every evidence is also present in a Cloud Object Storage bucket and is protected by a retention period of at least 365 days. Appends com.ibm.immutable_storage evidence to the summary.



* See [cocoa locker](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-clicocoa-locker) section on how to configure the Cloud Object Storage bucket.



* --dry-run: Has an effect when combined with --check-immutable-storage.
"junit.xml": "5aa5555aa55aa55a555aa5a5aa555555aaaa5aa5aa5555a55a5aa5aa5a5aaaaa",
},
...
}

Run the command to retrieve the attachment:

cocoa locker attachment get 5aa5555aa55aa55a555aa5a5aa555555aaaa5aa5aa5555a55a5aa5aa5a5aaaaa





 cocoa locker check 

Checks the required configuration and settings of the locker.

Currently, only the Cloud Object Storage based locker has a configuration requirement:



* Because every evidence must be kept for at least one year, the Cloud Object Storage bucket must be protected by a retention policy. Default retention period must be greater or equal to 365 days.



For more information, see [cocoa locker commands](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-clicocoa-locker-commands).

Required Environment Variables:

COS_API_KEY= Cloud Object Storage API Key
COS_BUCKET_NAME= Bucket Name where the evidence will be uploaded in the COS Instance
COS_ENDPOINT= The COS API Endpoint matching the region where the bucket is located

Run the command:

cocoa locker check --provider='cos'





 cocoa locker evidence check 

Validate the required evidence based on the checks present in the config file cocoa locker evidence check.

Required Environment Variables:

Options:

--org (Required) Owner of the evidence locker repo, defaults to EVIDENCE_LOCKER_REPO_OWNER
--repo (Required) Name of the evidence locker repo, defaults to EVIDENCE_LOCKER_REPO_NAME
--git-provider Git service provider ("github")
--git-token-path Git token path to read the secret from
--git-api-url Github API URL
--config-path (required) use this path to read the config file of all the required evidence check
pipeline_run_id: string; // ID of the pipeline run that generated the summary
evidences: Evidence[];
}

This summary does not perform any result aggregation. It is the raw data of collected v2 evidence, as they were found for assets that are related to a change request.







 v1 evidence (older format) 



 v1 evidence locker 

Evidence and related artifacts, such as logs and test results are stored in evidence lockers. Because pipeline runs can easily be deleted, pipelines are considered nondurable. To create a retention policy and audit log, evidence data that is related to compliance is stored in lockers.



 Git Repos and Issue Tracking 

Although it does not contain the data retention capabilities of Cloud Object Storage, Git is a simple implementation for an evidence locker.

The folder and file structure of the Git evidence locker is similar to the Cloud Object Storage implementation:

/raw
├── ci
| └── _PIPELINE_RUN_ID_A1
| └── _PIPELINE_RUN_ID_A2
| └── ..
| └── _PIPELINE_RUN_ID_An
| ├── artifacts
| └── evidences
│── cd
| └── _PIPELINE_RUN_ID_B1
| └── _PIPELINE_RUN_ID_B2
| └── ..
| └── _PIPELINE_RUN_ID_Bn
| ├── artifacts
| └── evidences





 IBM Cloud Object Storage 

For more information about Object Storage buckets, see [IBM Cloud Object Storage buckets as evidence locker](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-cos-bucket-evidence).







 v1 evidence collection 

The v1 evidence collection is the legacy evidence collection. To opt out of v1 evidence collection, see [Turning off legacy v1 evidence collection](https://cloud.ibm.com/docs/devsecops?topic=devsecops-turn-off-v1-evidence).
See [Integrated Services](https://cloud.ibm.com/docs/services/cloud-object-storage/basics?topic=cloud-object-storage-service-availability) for more details.

It isn't possible to use Aspera high-speed transfer if a targeted bucket has an [Immutable Object Storage](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-immutable) policy.



 Using the console 

If you add objects by using the console in a [supported region](https://cloud.ibm.com/docs/services/cloud-object-storage/basics?topic=cloud-object-storage-service-availability), you are prompted with an option to install the Aspera Connect client. This browser plug-in provides Aspera high-speed transfer to upload files or folders.



 Install Aspera Connect 



1. Select Install Aspera Connect client.
2. Follow the installation instructions for your operating system and browser.
3. Resume file or folder upload.



The Aspera Connect plug-in can also be installed from the [Aspera website](https://downloads.asperasoft.com/connect2/) directly. For help troubleshooting issues with the Aspera Connect plug-in, [see the documentation](https://downloads.asperasoft.com/en/documentation/8).

After the plug-in is installed, you have the option to set Aspera high-speed transfer as the default for any uploads to the target bucket that use the same browser. Select Remember my browser preferences. Options are also available in the bucket configuration page under Transfer options. These options allow you to choose between Standard and High speed as the default transport for uploads and downloads.

Typically, using the IBM Cloud Object Storage web-based console isn't the most common way to use Object Storage. The Standard transfer option limits objects size to 200 MB and the file name and key will be the same. Support for larger object sizes and improved performance (depending on network factors) is provided by Aspera high-speed transfer.
Using Aspera high-speed transfer 

Aspera high-speed transfer overcomes the limitations of traditional FTP and HTTP transfers to improve data transfer performance under most conditions, especially in networks with high latency and packet loss.

This feature is not currently supported in Object Storage for Satellite. [Learn more.](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-about-cos-satellite)

Instead of the standard HTTP PUT operation, Aspera high-speed transfer uploads the object by using the [FASP protocol](https://www.ibm.com/products/aspera/technology). Using Aspera high-speed transfer for uploads and downloads offers the following benefits:



* Faster transfer speeds
* Transfer large object uploads over 200 MB in the console and 1 GB by using an SDK or library
* Upload entire folders of any type of data, such as multi-media files, disk images, and any other structured or unstructured data
* Customize transfer speeds and default preferences
* Transfers can be viewed, paused, resumed, or cancelled independently



Aspera high-speed transfer is available in the IBM Cloud [console](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-asperaaspera-console) and can also be used programmatically by using an [SDK](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-asperaaspera-sdk).

Aspera high-speed transfer is available in certain regions only. See [Integrated Services](https://cloud.ibm.com/docs/services/cloud-object-storage/basics?topic=cloud-object-storage-service-availability) for more details.

It isn't possible to use Aspera high-speed transfer if a targeted bucket has an [Immutable Object Storage](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-immutable) policy.



 Using the console
Using Aspera high-speed transfer 

Aspera high-speed transfer overcomes the limitations of traditional FTP and HTTP transfers to improve data transfer performance under most conditions, especially in networks with high latency and packet loss.

This feature is not currently supported in Object Storage for Satellite. [Learn more.](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-about-cos-satellite)

Instead of the standard HTTP PUT operation, Aspera high-speed transfer uploads the object by using the [FASP protocol](https://www.ibm.com/products/aspera/technology). Using Aspera high-speed transfer for uploads and downloads offers the following benefits:



* Faster transfer speeds
* Transfer large object uploads over 200 MB in the console and 1 GB by using an SDK or library
* Upload entire folders of any type of data, such as multi-media files, disk images, and any other structured or unstructured data
* Customize transfer speeds and default preferences
* Transfers can be viewed, paused, resumed, or cancelled independently



Aspera high-speed transfer is available in the IBM Cloud [console](https://cloud.ibm.com/docs/cloud-object-storage/basics?topic=cloud-object-storage-asperaaspera-console) and can also be used programmatically by using an [SDK](https://cloud.ibm.com/docs/cloud-object-storage/basics?topic=cloud-object-storage-asperaaspera-sdk).

Aspera high-speed transfer is available in certain regions only. See [Integrated Services](https://cloud.ibm.com/docs/services/cloud-object-storage/basics?topic=cloud-object-storage-service-availability) for more details.

It isn't possible to use Aspera high-speed transfer if a targeted bucket has an [Immutable Object Storage](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-immutable) policy.



 Using the console
* Queued: PipelineRun is accepted for processing and runs when worker capacity is available.
* Waiting: PipelineRun is waiting to be queued.
* Cancelled: PipelineRun was cancelled by the system or by the user. The system cancels PipelineRun when the number of waiting runs exceeds the allowed limit.
* Error: PipelineRun contains errors that prevented it from being applied on the cluster. For more information about the cause of the error, see the run details.



For detailed information about a selected run, click any row in the table to view the Task definition and the steps in each PipelineRun definition. You can also view the status, logs, and details of each Task definition and step, and the overall status of the PipelineRun definition.

The retention period for PipelineRuns and their logs depends on the plan that is selected for the Continuous Delivery service instance. Tekton pipelines under the Professional plan are retained for one year. Tekton pipelines under the Lite plan are retained for 30 days. To retain any PipelineRuns beyond the retention period, in the PipelineRuns section, select **Actions > Download to download a .zip file.





 Viewing a Delivery Pipeline with the API 



1. [Obtain an IAM bearer token](https://cloud.ibm.com/apidocs/tekton-pipelineauthentication). Alternatively, if you are using an SDK, [obtain an IAM API key](https://cloud.ibm.com/iam/apikeys) and set the client options by using environment variables.

export CD_TEKTON_PIPELINE_APIKEY={api_key}
2. Get the pipeline data.



* Curl
* Java
* Node
* Python
* Go



curl -X GET https://api.{region}.devops.cloud.ibm.com/pipeline/v2/tekton_pipelines/{pipeline_id} -H 'Authorization: Bearer {iam_token}' -H 'Accept: application/json

import com.ibm.cloud.continuous_delivery.cd_tekton_pipeline.v2.CdTektonPipeline;
If you specify the --wait option, the subscription create waits for a maximum time in seconds, as set by the --wait-timeout option, for the subscription to become ready. If the subscription is not ready within the specified --wait-timeout period, the IBM Cloud Object Storage event subscription create fails. This value is optional. The default value is true.

--wait-timeout, --wto
: The length of time in seconds to wait for the IBM Cloud Object Storage event subscription to be ready. 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 15.





 Example 

The IBM Cloud Object Storage subscription listens for changes to an Object Storage bucket. The following example creates a COS subscription called mycosevent for a bucket called mybucket that is attached to an app called myapp. The --destination-type option specifies the type of the destination which is app or job. For this example, the --destination-type is app, which is the default for this option. The event is sent to the /events path by using the --path option so that the event is sent to https://<base application URL>/events.

ibmcloud ce subscription cos create --name mycosevent --destination myapp --bucket mybucket --destination-type app --path /events





 Example output 

Creating COS source 'mycosevent'...
Run 'ibmcloud ce subscription cos get -n mycosevent' to check the COS source status.
OK







 ibmcloud ce subscription cos delete 

Delete an IBM Cloud Object Storage event subscription.

ibmcloud ce subscription cos delete --name COS_SOURCE_NAME [--force] [--ignore-not-found] [--no-wait] [--quiet] [--wait] [--wait-timeout WAIT_TIMEOUT]



 Command Options 

--name, -n
: The name of the IBM Cloud Object Storage event subscription. This value is required.

--force, -f
Thus with more unique flows, more NICs can provide greater aggregate throughput.

Bonding works between a server and switch. However, MPIO works between a storage server and the host, even if a switch is in the path.

For more information, see one of the following articles.



* Red Hat Linux®: [Is the use of bonded NIC interfaces recommended with iscsi?](https://access.redhat.com/solutions/41899)
* Microsoft® Windows®: [NIC Teaming and ISCSI](https://social.technet.microsoft.com/Forums/en-US/441d2157-119d-4b1e-b40c-1aa3670e44a6/nic-teaming-and-iscsi?forum=winserverhyperv).
* VMware®: [Host requirements for link aggregation](https://kb.vmware.com/s/article/1001938?lang=en_US) or [iSCSI and LAG/LACP](https://core.vmware.com/blog/iscsi-and-laglacp).



* What latency can be expected from the Block Storage for Classic?

Target latency within the storage is <1 ms. The storage is connected to compute instances on a shared network, so the exact performance latency depends on the network traffic during the operation.
* I ordered a Block Storage for Classic LUN in the wrong data center. Is it possible to move or migrate storage to another data center?

You need to order new Block Storage for Classic in the correct data center, and then cancel the Block Storage for Classic device that you ordered in the wrong location. When the volume is canceled, the request is followed by a 24-hour reclaim wait period. You can still see the volume in the console during those 24 hours. Billing for the volume stops immediately. When the reclaim period expires, the data is destroyed and the volume is removed from the console, too.
* How can we tell which Block Storage for Classic volumes are encrypted?
This plan summarizes all of the actions that must be run to delete the Continuous Delivery service instance.

terraform plan
5. Apply the Terraform execution plan. Terraform takes all of the required actions to delete the Continuous Delivery service instance.

terraform apply







 Restoring a deleted service instance 

After you delete an instance of the Continuous Delivery service, you can restore the deleted service instance within the data retention period of seven days. After the seven-day period expires, the service instance is permanently deleted.

To view which service instances are available for restoration and to restore a deleted service, see [Using resource reclamations](https://cloud.ibm.com/docs/account?topic=account-resource-reclamation). If you try to restore a deleted service and an active Continuous Delivery service instance exists, the restoration is blocked. For more information about how to view the details for a resource reclamation, see [Listing reclaimed resources by using the CLI](https://cloud.ibm.com/docs/account?topic=account-resource-reclamation&interface=cli) or [Listing reclaimed resources by using the API](https://cloud.ibm.com/docs/account?topic=account-resource-reclamation&interface=api).

You can have one active instance of Continuous Delivery only in a region and resource group. After you delete an instance of the Continuous Delivery service from a region and resource group, you can restore the deleted service instance to create a service instance again within the data retention period of seven days. Alternatively, you can permanently remove the deleted service instance by using the [ibmcloud resource reclamation-delete](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_commands_resourceibmcloud_resource_reclamation_delete) command, and then [create a Continuous Delivery service](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-create_cd_service) instance again.
-H 'Content-MD5: exuBoz2kFBykNwqu64JZuA==' 
-H 'Content-Type: text/plain; charset=utf-8' 
-d $'<ObjectLockConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<ObjectLockEnabled>Enabled</ObjectLockEnabled>
<Rule>
<DefaultRetention>
<Days>30</Days>
<Mode>COMPLIANCE</Mode>
</DefaultRetention>
</Rule>
</ObjectLockConfiguration>'

A successful request returns a 200 response.





 View Object Lock configuration for a bucket 

curl -X "GET" "https://$BUCKET.s3.$REGION.cloud-object-storage.appdomain.cloud/?object-lock" 
-H 'Authorization: bearer $TOKEN'

This returns an XML response body with the appropriate schema:

<ObjectLockConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<ObjectLockEnabled>string</ObjectLockEnabled>
<Rule>
<DefaultRetention>
<Days>30</Days>
<Mode>COMPLIANCE</Mode>
</DefaultRetention>
</Rule>
</ObjectLockConfiguration>





 Add or extend a retention period for an object 

The Object Lock configuration is provided as XML in the body of the request. New requests will overwrite any existing replication rules that are present on the object, provided the RetainUntilDate is farther in the future than the current value.



 Header Type Description 

 Content-MD5 String Required: The base64 encoded 128-bit MD5 hash of the payload, which is used as an integrity check to ensure that the payload wasn't altered in transit. 



Optionally, you can specify the version for which to apply the RetainUntilDate.





 Optional query parameters 



 Parameter Required? Type Description 

 versionID Optional string Version ID.