vania-janet/multiturn-rag-retrieval-data huggingface dataset:
The PCI network adapter attached to the IBM Cloud bare metal server is configured within vSphere as a vSphere Distributed Switch (vDS) with the network adapters as uplink. A dedicated vSAN kernel port group is configured for the vSAN VPC subnet and is located within the vDS. Jumbo frames (MTU 9000) are enabled for the private vDS.

vSAN does not load balance traffic across uplinks. High availability (HA) for the uplink is provided by the SmartNIC.

For more information about physical NIC connections, see [Networking overview for IBM Cloud Bare Metal Servers on VPC](https://cloud.ibm.com/vpc?topic=vpc-bare-metal-servers-network&interface=ui).





 vSAN storage policy 

When vSAN is enabled and configured, storage policies are configured to define the VM storage characteristics. Storage characteristics specify different levels of service for different VMs. With the roll-your-own VMware solution in VPC, you are responsible for configuring the storage policies based on your needs.

The default storage policy in this design tolerates a single failure. It is configured with erasure coding, with the Failure tolerance method set to RAID-5/6 (Erasure Coding) - Capacity and Primary level of failures set to 1. The RAID 5 configuration requires a minimum of four hosts.

Alternatively, you can choose the RAID 6 configuration with Failure tolerance method set to RAID-5/6 (Erasure Coding) - Capacity and Primary level of failures set to 2. The RAID 6 configuration requires a minimum of six hosts. Deduplication and compression are normally enabled in the default storage policy but can be disabled if needed.

An vSAN uses the default policy unless otherwise specified from the vSphere console. When a custom policy is configured, vSAN guarantees it when possible. However, if the policy cannot be guaranteed, it is not possible to provision a VM that uses the policy unless it is enabled to force provisioning.

Storage policies must be reapplied after adding new ESXi hosts or patching ESXi hosts.





 vSAN storage settings 

vSAN settings are configured based on best practices for deploying VMware solutions within IBM Cloud.
Why does installing the Object storage Helm plug-in fail? 

Virtual Private Cloud

Classic infrastructure

 What’s happening 

When you install the IBM Cloud Object Storage ibmc Helm plug-in, the installation fails with one of the following errors:

Error: symlink /Users/iks-charts/ibm-object-storage-plugin/helm-ibmc /Users/ibm/.helm/plugins/helm-ibmc: file exists

Error: fork/exec /home/iksadmin/.helm/plugins/helm-ibmc/ibmc.sh: permission denied

 Why it’s happening 

When the ibmc Helm plug-in is installed, a symlink is created from the /.helm/plugins/helm-ibmc directory for Linux systems or the /Library/helm/plugins/helm-ibmc directory for Mac OS to the directory where the ibmc Helm plug-in is located on your local system, which is usually in ./ibmcloud-object-storage-plugin/helm-ibmc.

When you remove the ibmc Helm plug-in from your local system, or you move the ibmc Helm plug-in directory to a different location, the symlink is not removed.

If you see a permission denied error, you don't have the required read, write, and execute permission on the ibmc.sh bash file so that you can execute ibmc Helm plug-in commands.

 How to fix it 

Review the following steps based on the error type.

For symlink errors:



1. Remove the IBM Cloud Object Storage Helm plug-in. Linux

rm -rf /.helm/plugins/helm-ibmc

Mac OS

rm -rf /Library/helm/plugins/helm-ibmc for macOS
2. Follow the [documentation](https://cloud.ibm.com/docs/containers?topic=containers-storage_cos_install) to re-install the ibmc Helm plug-in and the IBM Cloud Object Storage plug-in.



For permission errors:



1. Change the permissions for the ibmc plug-in. Linux
Why does installing the Object storage Helm plug-in fail? 

Virtual Private Cloud

Classic infrastructure

 What’s happening 

When you install the IBM Cloud Object Storage ibmc Helm plug-in, the installation fails with one of the following errors:

Error: symlink /Users/iks-charts/ibm-object-storage-plugin/helm-ibmc /Users/ibm/.helm/plugins/helm-ibmc: file exists

Error: fork/exec /home/iksadmin/.helm/plugins/helm-ibmc/ibmc.sh: permission denied

 Why it’s happening 

When the ibmc Helm plug-in is installed, a symlink is created from the /.helm/plugins/helm-ibmc directory for Linux systems or the /Library/helm/plugins/helm-ibmc directory for Mac OS to the directory where the ibmc Helm plug-in is located on your local system, which is usually in ./ibmcloud-object-storage-plugin/helm-ibmc.

When you remove the ibmc Helm plug-in from your local system, or you move the ibmc Helm plug-in directory to a different location, the symlink is not removed.

If you see a permission denied error, you don't have the required read, write, and execute permission on the ibmc.sh bash file so that you can execute ibmc Helm plug-in commands.

 How to fix it 

Review the following steps based on the error type.

For symlink errors:



1. Remove the IBM Cloud Object Storage Helm plug-in. Linux

rm -rf /.helm/plugins/helm-ibmc

Mac OS

rm -rf /Library/helm/plugins/helm-ibmc for macOS
2. Follow the [documentation](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_cos_install) to re-install the ibmc Helm plug-in and the IBM Cloud Object Storage plug-in.



For permission errors:



1. Change the permissions for the ibmc plug-in. Linux
* <QUEUE_MANAGER_NAME> - this is 'queueManagerName' in the file coordinationQMgrConnectionDetails.json
* -c informs runmqsc it should connect to a remote queue manager using the MQSERVER variable



* e.g. - runmqsc -c -u mamgainp -w60 QM_COORD



4. The terminal will prompt you for a Password



* This is your <ADMIN_API_KEY> = 'apiKey' in the file platformApiKey.json



5. The terminal will now be waiting for input. Do not close this terminal as we will use this terminal to create MQ objects.
6. Create the MQ objects required by the queue manager to work as a coordination queue manager that targets your mq on cloud queue manager



* When you ran fteSetupCoordination in step 2, an mqsc file will have been created at location MQ_DATA_PATHmqftconfigcoordination_qmgr_name<coordination_qmgr_name>.mqsc. Copy and paste the content of this file into your terminal.



![Image showing 'runmqsc' command that creates MQ objects required by the coordination queue manager](https://cloud.ibm.com/docs-content/v1/content/3a120b16db5fdc3e70d071af8a63ce5515c1b096/mqcloud/images/mqoc_fte_setup_coordination_qmgr_2.png)



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





 Setting up a Command Queue Manager 

In this section, you will setup a command queue manager that is targeted at the MQ on Cloud Queue Manager. As part of the configuration for the Command Queue Manager, following commands have to be executed:



1. Switch to the admin terminal you setup previously.
2. Run the following command
* UI
* API







 Single-page apps 

With IBM Cloud® App ID, you can quickly add authorization and authentication to your single-page applications (SPA). An SPA runs entirely in your browser, doesn't have a backend that you manage, and does not require that the page reload while the application is in use. Some common frameworks that are used with SPAs are [Angular](https://angular.io/) and [React](https://reactjs.org/).

Does your app have a backend that you control? SPA is not the flow for you. Try the [web app flow](https://cloud.ibm.com/docs/appid?topic=appid-web-apps)!



 Understanding the flow 

Although it is the current industry standard for SPAs, the OAuth working group no longer recommends the use of the implicit flow due to several security concerns. Based on their advice, App ID is configured to use the [Authorization Code flow with PKCE](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-04).

Zoom

![SPA authorization flow](https://cloud.ibm.com/docs-content/v1/content/27ecaa7a29890634603881a8e64789974a29916b/appid/images/spa.png)

Figure 1. The authorization flow of single-page applications



1. A user attempts to log in to your single-page application.
2. The App ID SDK creates a code verifier for the authorization request, which is the plain text version of the code challenge. Along with the authorization request, the client sends the code challenge and the challenge method that is used to encode the challenge.
3. The authentication flow is started by App ID in a new window.
4. The user chooses an identity provider to authenticate with and completes the sign-in process.
5. The App ID SDK on the application receives the grant code
6.
Methods 

There are seven methods that MAY be supported by a resource URI. A summary table of each method's basic attributes is listed below, followed by detailed guidelines for the use of each method.



 Summary 



HTTP methods

 Method Request body Response body Safe Idempotent 

 GET No Yes Yes Yes 
 HEAD No No Yes Yes 
 POST Yes Yes No No 
 PUT Yes Yes No Yes 
 PATCH Yes Yes No No 
 DELETE No Yes No Yes 
 OPTIONS No Yes Yes Yes 







 GET 

The response to a successful GET request SHOULD contain the state of a resource or collection of resources, based on the request URI. A GET request MUST be safe and therefore MUST NOT have side effects

[1]. If a GET request contains a body, the body MUST be ignored and therefore MUST NOT cause an error.[2]





 HEAD 

The response to a successful HEAD request MUST contain the exact set of headers that the response to an otherwise-identical GET request would contain, but MUST NOT include a response body.

[3]This can be used for a client to make optimizations if it needs only the information contained in response headers.

If HEAD-specific optimizations are not feasible, the handling of a HEAD request MAY be implemented internally by using the same code path as the handling of the corresponding GET request and subsequently discarding the response body. As with a GET request, a HEAD request MUST be safe and its body MUST be ignored.





 POST 



 For creation 

The POST URI used to create a resource SHOULD be the same as the GET URI for listing resources of the same kind.

[4]For example, if GET /users lists all users, and users can be created by a client, then POST /users SHOULD create a user.

The response to a POST request which successfully and synchronously creates a resource MUST have the status code 201 Created and a Location header with the URI of the newly-created resource

[5]and SHOULD include the created resource in the response body.
Processing incident and nonincident issues 

The following types of issues are supported:



* Incident issues, which can arise due to vulnerabilities or CVEs found inside the code or the deployed artifacts.
* Nonincident issues, which do not arise from vulnerabilities, but rather represent a deviation from the compliance posture. For example, unit test failures and branch protection check failures.





 Adding default assignees to issues 

You can define multiple default assignees for the issue by using the incident-assignees pipeline parameter. The incident-assignees parameter can be used only with GitHub accounts and GitLab Premium accounts. For more information about the incident-assignees parameter, see [Assigning issues to users](https://cloud.ibm.com/docs/devsecops?topic=devsecops-issue-processingassign-issues).

You can also set a default issue assignee for the pipeline with the incident-assignee pipeline parameter, however this parameter is deprecated and will be removed with the v1 evidence (legacy) collection.





 Filtering issues 

You can filter and search for issues by using default and custom labels. The following default labels are assigned to the issues upon creation or update:



* The [scan type](https://cloud.ibm.com/docs/devsecops?topic=devsecops-incident-issuesdue-date-supported-tools) that is used for the issue processing is added to the incident issue as a tool label (for example, tool:cra, tool:va, tool:sonarqube).
* A severity label is also assigned to issues. The severity categories are defined based on the scan results and can be one of the following: severity:critical, severity:high, severity:medium, severity:low, severity:informational.
* The has-exempt is a VA tool-specific label that is assigned to the issue if it is exempted based on the scan result. If the exempt status is not included in the scan result, you can exempt the issue manually by assigning the exempt label and adding a link to the source of the exempt issue ticket in a comment.
For production environments, the IBM SRE team highly discourages requests to run sql scripts with insert/update/delete statement(s). These are considered high risk and can break overall data integrity. SRE will only execute statements that have been tested by the client on their non-production environments. Every effort should be made to use [automation scripts](https://www.ibm.com/docs/en/maximo-manage/continuous-delivery?topic=scripts-automation) or standard tools through the Maximo front end rather than altering data directly. If a SQL script of this type is required, clients can request this via [IBM case ticket](https://www.ibm.com/mysupport), with sql script attached along with business justification as to why its needed and why changing from Maximo front end is not possible. There is a 3 day lead time for SQL scripts. The case needs to include:



* SQL Script (as an attachment)
* Design or description of what the script is doing to the data
* Business justification of why the script is required
* Technical justification of why the script's commands cannot be done via Maximo front end using DB configuration
* Request to take full offline backup of target database prior to running script



SQL Script Limitations:



* SQL scripts cannot be run in Non-Production environments.
* DBC Scripts are not allowed in any environment.
* Backups will be done in offline mode which will require target site to be down / unavailable. Backups can take several hours based on database size.
* IBM SRE team is not responsible for script not working, script corrections and any issues that arise during or after sql execution. If issues arise, IBM SRE can only restore from backup.
* Any outages caused by the execution of the script and time to recover will not be counted as an SLA breach.







 How to Access IBM COS (Cloud Object Storage) Buckets 



* To access IBM COS bucket you have to configure Rclone. Rclone is the utility via which you can access IBM COS bucket(s) and upload/download the content.
* To configure Rclone please use steps below.
Managing nonincident issues 

Unlike incident issues that can arise due to vulnerabilities or CVEs found inside the code or the deployed artifacts, nonincident issues result from failing unit tests, failing acceptance tests, failing branch protection checks, an image signing failure, or an image not being pulled from the registry because of a bad token or expired credentials. These scenarios are not because of some vulnerabilities but are a deviation from the compliance posture. As a result, nonincident issues are captured whenever the pipelines encounter such scenarios.

The [collect-evidence script](https://cloud.ibm.com/docs/devsecops?topic=devsecops-devsecops-collect-evidence) captures nonincident issues inside the issues repository, and attaches the issue with the collected evidence. The collect-evidence script relies on the [cocoa incident process-legacy](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-cliincident-process-legacy) command of the DevSecOps CLI tool, which can create issues or close existing issues based on the status of the current run.



 Nonincident issue processing 

Nonincident issues do not have a due date assigned to them by default. Any pipeline can open nonincident issues, and in a subsequent run, if the issue is no longer detected for the incident-tool-subject combination, the issue is automatically closed. Issues can be found during build, deployment, or during the continuous monitoring phase.

For nonincident issues that are found during a CI run, a combination of the evidence_type and the app repo branch is used to construct the issue title so that a unit test failure found on branch master is dealt with separately from a unit test failure on branch dev. A similar combination is used for such issues that are found from the CC pipeline. Issues coming from CD pipeline have a different grouping criteria, where the combination of the evidence type id, target environment, and the pipeline namespace is used to construct the title of the issue. This different grouping criteria ensure that the issues found on CI and CC are not interfered by the CD run for similar tests like an acceptance test.
Managing alternative toolchains in different regions 

You can define your toolchain by using Terraform Configuration Language, and then apply and maintain your toolchain definition in two regions: a primary region with active pipelines, and an alternative region with idle pipelines. If you use Git Repos and Issue Tracking, you can also [mirror your Git repos](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-cd-ha-dr-mirrorgit) from the primary region to the alternative region. Maintaining primary and alternative toolchains and Git repos provides faster failover and redundancy. It also ensures smooth operation if issues arise in the primary region. By codifying your toolchain in Terraform, you can update your toolchain and apply the changes to both regions.

For more information about using Terraform, see [Setting up Terraform for Continuous Delivery](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-terraform-setup).
Debugging common CLI issues with clusters 

Virtual Private Cloud

Classic infrastructure

Review the following common reasons for CLI connection issues or command failures.



 Firewall prevents running CLI commands 

 What’s happening 

When you run ibmcloud, kubectl,oc, or calicoctl commands from the CLI, they fail.

 Why it’s happening 

You might have corporate network policies that prevent access from your local system to public endpoints via proxies or firewalls.

 How to fix it 

[Allow TCP access for the CLI commands to work](https://cloud.ibm.com/docs/openshift?topic=openshift-firewallfirewall_bx).

This task requires the [Administrator IBM Cloud IAM platform access role](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-perms) for the cluster.





 kubectl or oc commands don't work 

 What’s happening 

When you run kubectl or oc commands against your cluster, your commands fail with an error message similar to the following.

No resources found.
Error from server (NotAcceptable): unknown (get nodes)

invalid object doesn't have additional properties

error: No Auth Provider found for name "oidc"

 Why it’s happening 

You have a different version of kubectl than your cluster version.

[Kubernetes does not support](https://kubernetes.io/releases/version-skew-policy/)kubectl client versions that are 2 or more versions apart from the server version (n +/- 2). If you use a community Kubernetes cluster, you might also have the Red Hat OpenShift version of kubectl, which does not work with community Kubernetes clusters.

To check your client kubectl version against the cluster server version, run oc version --short.

 How to fix it
func URLSession(session: NSURLSession, didReceiveChallenge challenge: NSURLAuthenticationChallenge, completionHandler: (NSURLSessionAuthChallengeDisposition, NSURLCredential?) -> Void) {
completionHandler(NSURLSessionAuthChallengeDisposition.UseCredential, NSURLCredential(forTrust: challenge.protectionSpace.serverTrust!))
}
}
// create an NSURLSession that uses the trusting delegate
let session = NSURLSession(configuration: NSURLSessionConfiguration.defaultSessionConfiguration(), delegate: NetworkUtilsDelegate(), delegateQueue:NSOperationQueue.mainQueue())
// set the SDK to use this urlSession instead of the default shared one
whisk.urlSession = session



 Support for qualified names with mobile SDK 

All actions and triggers have a fully qualified name that is made up of a namespace, a package, and an action or trigger name. The SDK can accept these elements as parameters when you are invoking an action or Firing a trigger. The SDK also provides a function that accepts a fully qualified name that looks like /mynamespace/mypackage/nameOfActionOrTrigger. The qualified name string supports unnamed default values for namespaces and packages that all Cloud Functions users have, so the following parsing rules apply:



* qName = "foo" results in namespace = default, package = default, action/trrigger = "foo"
* qName = "mypackage/foo" results in namespace = default, package = mypackage, action/trigger = "foo"
* qName = "/mynamespace/foo" results in namespace = mynamespace, package = default, action/trigger = "foo"
* qName = "/mynamespace/mypackage/foo" results in namespace = mynamespace, package = mypackage, action/trigger = "foo"



All other combinations issue a WhiskError.QualifiedName error.
SDK References



* Classes



* [CreateBucketRequest](https://ibm.github.io/ibm-cos-sdk-java/com/ibm/cloud/objectstorage/services/s3/model/CreateBucketRequest.html)
* [EncryptionType](https://ibm.github.io/ibm-cos-sdk-java/)



* Methods



* [createBucket](https://ibm.github.io/ibm-cos-sdk-java/com/ibm/cloud/objectstorage/services/s3/AmazonS3.htmlcreateBucket-com.ibm.cloud.objectstorage.services.s3.model.CreateBucketRequest-)











 Using Aspera High-Speed Transfer 

By installing the [Aspera high-speed transfer library](https://cloud.ibm.com/docs/cloud-object-storage/basics?topic=cloud-object-storage-asperaaspera-packaging) you can utilize high-speed file transfers within your application. The Aspera library is closed-source, and thus an optional dependency for the COS SDK (which uses an Apache license).

Each Aspera high-speed transfer session spawns an individual ascp process that runs on the client machine to perform the transfer. Ensure that your computing environment can allow this process to run.

You will need instances of the S3 Client and IAM Token Manager classes to initialize the AsperaTransferManager. The s3Client is required to get FASP connection information for the COS target bucket. The tokenManager is required to allow the Aspera high-speed transfer SDK to authenticate with the COS target bucket.



 Initializing the AsperaTransferManager
Debugging common CLI issues with clusters 

Virtual Private Cloud

Classic infrastructure

Review the following common reasons for CLI connection issues or command failures.



 Firewall prevents running CLI commands 

 What’s happening 

When you run ibmcloud, kubectl, or calicoctl commands from the CLI, they fail.

 Why it’s happening 

You might have corporate network policies that prevent access from your local system to public endpoints via proxies or firewalls.

 How to fix it 

[Allow TCP access for the CLI commands to work](https://cloud.ibm.com/docs/containers?topic=containers-firewallfirewall_bx).

This task requires the [Administrator IBM Cloud IAM platform access role](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms) for the cluster.





 kubectl commands don't work 

 What’s happening 

When you run kubectl commands against your cluster, your commands fail with an error message similar to the following.

No resources found.
Error from server (NotAcceptable): unknown (get nodes)

invalid object doesn't have additional properties

error: No Auth Provider found for name "oidc"

 Why it’s happening 

You have a different version of kubectl than your cluster version.

[Kubernetes does not support](https://kubernetes.io/releases/version-skew-policy/)kubectl client versions that are 2 or more versions apart from the server version (n +/- 2). If you use a community Kubernetes cluster, you might also have the Red Hat OpenShift version of kubectl, which does not work with community Kubernetes clusters.

To check your client kubectl version against the cluster server version, run kubectl version --short.

 How to fix it 

[Install the version of the CLI](https://cloud.ibm.com/docs/containers?topic=containers-cli-install) that matches the version of your cluster.