vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Are you getting a "CosEndpoint.APIKey is not valid" error when creating a COS target? 

When creating an IBM Cloud Object Storage target, the message Your request has failed because the value of CosEndpoint.APIKey is not valid. Set a valid value in your target request and try again. is returned.

  What’s happening 

Your request fails with an error message and a code of invalid_value.

  Why it’s happening 

You are trying to configure a COS target and have not specified --api-key or --service-to-service-enabled TRUE on the request.

  How to fix it 

Retry the request after adding --api-key with your [COS bucket API key.](https://cloud.ibm.com/docs/atracker?topic=atracker-target_v2_cos&interface=clicos_apikey) or --service-to-service-enabled TRUE as appropriate for your environment. Specifying --service-to-service-enabled TRUE requires that you have [service-to-service authorization](https://cloud.ibm.com/docs/atracker?topic=atracker-target_v2_cos&interface=clicos_s2s) configured for your COS bucket.
How to fix it 

This error requires that you contact [IBM support](https://cloud.ibm.com/docs/vpc?topic=vpc-getting-help&interface=clisupport-cases). Provide the error logs for their reference.





 Bulk migration of file share profiles is not supported 

 What’s happening 

File Storage for VPC does not support changing file storage profiles of multiple shares at the same time. You can update the profile for a single share but bulk migration is not supported.

 Why it’s happening 

You cannot use the UI, CLI, or API to update the profiles of multiple file shares in a single operation.

 How to fix it 

For migrating multiple shares, you must create your own script. The script can list the shares that you want to update, and then go through the list of shares to update each individual share profile.

Create a script file to list your file shares, parse the list, and then individually update the profile for each file share. Make sure you set execute permission on your script file. In your script:



1. List your file shares in your region by specifying a GET /shares request. To keep the operation manageable, you might want to set a limit on the number of shares.

curl -X GET "$vpc_api_endpoint/v1/shares?limit=20?version=2023-01-11&generation=2&maturity=beta" -H "Authorization: $iam_token"
2. Parse each file in the list and update each file share by making separate PATCH/ shares/{share_id} requests.

curl -X PATCH "$rias_endpoint/v1/shares/432f1a4d-4aac-4ba1-922c-76fdbcbeb1e3?version=2023-07-11&generation=2&maturity=beta" -H "Authorization: $iam_token" -d '{
-d '{
"profile": {
"name": "dp2"
},
}'
{: codeblock}
3.
Are you having access issues when you were able to do so before? 

When attempting to manage IBM Cloud Activity Tracker Event Routing, you are unable to do so and are getting errors indicating you do not have access to do so.

  What’s happening 

Your requests fail indicating you do not have access or the correct privileges.

  Why it’s happening 

If Administrator privileges are set to All Identity and Access enabled services in Cloud Identity and Access Management you will be unable to manage the IBM Cloud Activity Tracker Event Routing configuration. Administrator privileges must be configured for Activity Tracker or [All Account Management Services](https://cloud.ibm.com/docs/account?topic=account-account-services) in Cloud Identity and Access Management.

  How to fix it 

Reconfigure the Administrator privileges in Cloud Identity and Access Management and retry your IBM Cloud Activity Tracker Event Routing requests.
Why do images fail to pull from registry with ImagePullBackOff or authorization errors? 

Virtual Private Cloud

Classic infrastructure

 What’s happening 

When you deploy a workload that pulls an image from IBM Cloud Container Registry, your pods fail with an ImagePullBackOff status.

kubectl get pods

NAME READY STATUS RESTARTS AGE
<pod_name> 0/1 ImagePullBackOff 0 2m

When you describe the pod, you see authentication errors similar to the following.

kubectl describe pod <pod_name>

Failed to pull image "<region>.icr.io/<namespace>/<image>:<tag>" ... unauthorized: authentication required
Failed to pull image "<region>.icr.io/<namespace>/<image>:<tag>" ... 401 Unauthorized

Failed to pull image "registry.ng.bluemix.net/<namespace>/<image>:<tag>" ... unauthorized: authentication required
Failed to pull image "registry.ng.bluemix.net/<namespace>/<image>:<tag>" ... 401 Unauthorized

 Why it’s happening 

Your cluster uses an API key that is stored in an [image pull secret](https://cloud.ibm.com/docs/containers?topic=containers-registrycluster_registry_auth) to authorize the cluster to pull images from IBM Cloud Container Registry.

By default, new clusters have image pull secrets that use API keys so that the cluster can pull images from any regional icr.io registry for containers that are deployed to the default Kubernetes namespace.

 How to fix it 



1. Verify that you use the correct name and tag of the image in your deployment YAML file.

ibmcloud cr images
2. Check your [pull traffic and storage quota](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_quota). If the limit is reached, free up used storage or ask your registry administrator to increase the quota.

ibmcloud cr quota
3.
Why do images fail to pull from registry with ImagePullBackOff or authorization errors? 

Virtual Private Cloud

Classic infrastructure

 What’s happening 

When you deploy a workload that pulls an image from IBM Cloud Container Registry, your pods fail with an ImagePullBackOff status.

oc get pods

NAME READY STATUS RESTARTS AGE
<pod_name> 0/1 ImagePullBackOff 0 2m

When you describe the pod, you see authentication errors similar to the following.

oc describe pod <pod_name>

Failed to pull image "<region>.icr.io/<namespace>/<image>:<tag>" ... unauthorized: authentication required
Failed to pull image "<region>.icr.io/<namespace>/<image>:<tag>" ... 401 Unauthorized

Failed to pull image "registry.ng.bluemix.net/<namespace>/<image>:<tag>" ... unauthorized: authentication required
Failed to pull image "registry.ng.bluemix.net/<namespace>/<image>:<tag>" ... 401 Unauthorized

 Why it’s happening 

Your cluster uses an API key that is stored in an [image pull secret](https://cloud.ibm.com/docs/openshift?topic=openshift-registrycluster_registry_auth) to authorize the cluster to pull images from IBM Cloud Container Registry.

By default, new clusters have image pull secrets that use API keys so that the cluster can pull images from any regional icr.io registry for containers that are deployed to the default Red Hat OpenShift project.

 How to fix it 



1. Verify that you use the correct name and tag of the image in your deployment YAML file.

ibmcloud cr images
2. Check your [pull traffic and storage quota](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_quota). If the limit is reached, free up used storage or ask your registry administrator to increase the quota.

ibmcloud cr quota
3.
Why do I get a Volume not attached error when trying to expand a Block Storage for VPC volume? 

Virtual Private Cloud

  What’s happening 

When you edit a Block Storage for VPC and update the spec.resources.requests.storage section to expand your volume, you see the following error:

Volume not attached

  Why it’s happening 

You tried to expand the volume size of an existing Block Storage for VPC PVC that is not mounted by a pod. Only volumes mounted by app pods can be expanded.

  How to fix it 

Verify that your PVC supports volume expansion, then create an app pod that uses your PVC.



1.  Describe your existing PVC. Verify that allowVolumeExpansion is set to true.

kubectl describe pvc <pvc-name>
2.  Create an app pod that uses your PVC and deploy it to your cluster.
3.  Edit the PVC and increase the value in the spec.resources.requests.storage field.

kubectl edit pvc <pvc-name>
4.  Get the details of your PVC and make a note of the PV name.

kubectl get pvc <pvc-name>
5.  Describe your PV and make a note of the volume ID

kubectl describe PV
6.  Get the details of your Block Storage for VPC volume and verify the capacity.

ibmcloud is vol <volume-ID>
A host cannot be authorized to access LUNs of differing OS types at the same time. A host can be authorized to access LUNs of a single OS type. If you attempt to authorize a host to access multiple LUNs with different OS types, the operation results in an error.





 Revoking a host's access to Block Storage for Classic in the UI 

If you want to stop the access from a host to a particular storage LUN, you can revoke the access. Upon revoking access, the host connection is dropped from the LUN. The operating system and applications on that host can't communicate with the LUN anymore.

To avoid host side issues, unmount the storage LUN from your operating system before you revoke the access to avoid missing drives or data corruption.

You can revoke access from the Device List or the Storage view.



 Revoking access from the Device List 



1. In the [IBM Cloud® console](https://cloud.ibm.com/classic-gen1), click the Classic Infrastructure icon. Then, click Devices > Device List and double-click the appropriate device.
2. Select the Storage tab.
3. You are presented with a list of storage LUNs that this particular host has access to. The list is grouped by storage type (block, file, other). Next to the Volume name, click Actions, and click Revoke Access.
4. Confirm that you want to revoke the access for a LUN because the action can't be undone. Click Yes to revoke LUN access or No to cancel the action.



If you want to disconnect multiple LUNs from a specific host, you need to repeat the Revoke Access action for each LUN.





 Revoking access from the Storage View 



1. Click Storage > Block Storage for Classic, and select the LUN from which you want to revoke access.
2. Click Authorized Hosts.
3. Click Actions!
=== Check connectivity to link control plane ===
=== Test Failure Summary: ===
redhatOS - error checking RHN configuration with subscription-manager: exit status 1
network - wrong number of network interfaces (expected 2, found: 3: [1: lo, 2: eth0, 3: eth1])
network - Could not create request: dial tcp 169.62.10.162:443: connect: connection refused
network - Could not create request: dial tcp 169.63.75.82:443: connect: connection refused
network - Could not create request: dial tcp 169.63.94.210:443: connect: connection refused
network - Could not create request: dial tcp 169.63.111.82:443: connect: connection refused
network - Could not create request: dial tcp 169.63.149.122:443: connect: connection refused
network - Could not create request: dial tcp 169.63.158.82:443: connect: connection refused
network - Could not create request: dial tcp 169.63.160.130:443: connect: connection refused
cleaned up temp dir: /tmp/sathostcheck-3139302841
4. Review the test failure summary. Depending on the failure, review the requirements and update your hosts.



* [Host system requirements](https://cloud.ibm.com/docs/satellite?topic=satellite-host-reqs)
* [Host storage requirements](https://cloud.ibm.com/docs/satellite?topic=satellite-reqs-host-storage)
* [Host network requirements](https://cloud.ibm.com/docs/satellite?topic=satellite-reqs-host-network)
* [Host outbound connectivity requirements](https://cloud.ibm.com/docs/satellite?topic=satellite-reqs-host-network-outbound) and the region-specific outbound connectivity requirements for the region where you created your location.



5. If the host check succeeds, you can continue attaching the host to your location.
Select both the roles (Reader, and Object Writer) to assign access to the source service that accesses the target service.

If you have selected only one of these two roles (Reader or Object Writer) during the service to service authorization, you may endup with not able to write or read from the IBM Cloud Object Storage bucket. You will get an error for service to service authorization failure in these cases. Make sure to recreate an authorization between the services with both the roles selected.
9. Click Authorize.







 Creating an authorization by using the CLI 

To authorize a source service to access a target service, run the ibmcloud iam authorization-policy-create command.

For more information about all of the parameters that are available for this command, see [ibmcloud iam authorization-policy-create](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_commands_iamibmcloud_iam_authorization_policy_create).







 How to find the Bucket name in the IBM Cloud Object Storage service instance? 



1. Login to your IBM Cloud account.
2. Navigate to Resource List in the menu.
3. Navigate to Storage in the Resource list.
4. Click the IBM Cloud Object Storage name that will display your IBM Cloud Object Storage console.
5. In the IBM Cloud Object Storage console, navigate to Buckets.
6. Select and copy the required Bucket name. Use this copied Bucket name in the Collect Failed Events screen.







 How to find the Endpoint URL of the IBM Cloud Object Storage service instance? 

Endpoints are used with your credentials (Bucket name, API Key, SDK) to tell your service where to look for your bucket.



1. Login to your IBM Cloud account.
2. Navigate to Resource List in the menu.
3. Navigate to Storage in the Resource list.
4. Click the IBM Cloud Object Storage name that will display your IBM Cloud Object Storage console.
5. In the IBM Cloud Object Storage console, navigate to Buckets in the menu.
6. Click the required Bucket name to view the Bucket configuration details.
Are you getting a "setting limit" error when creating a target? 

When creating a default target, the following message is returned: Your request has failed because default_targets per setting limit 2 is reached..

  What’s happening 

Your request fails with an error message and a code of invalid_value.

  Why it’s happening 

You are trying to create or update your settings and specified more than two default target values (--default-targets) on the request.

  How to fix it 

[Only two default target values are supported.](https://cloud.ibm.com/docs/atracker?topic=atracker-settings) Retry your request specifying only two default targets for --default-targets.
The following changes were made in build 8052:

partitioned_indexes field
: Accessing the database information endpoint (/db/) for a partitioned database now includes information about the contained partitioned indexes. The new field, partitioned_indexes, contains the following information:



* The current number of partitioned indexes in the database (count).
* A breakdown of those indexes by type (indexes).
* The maximum partitioned indexes allowed for this database (limit).









 March 2019 



 15 March 2019 

The following changes were made in build 8048:

Improvements
: Internal bug fixes.





 1 March 2019 

The following changes were made in build 8038:

Partition queries
: Allow POST when you search [partition queries](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-database-partitioningdatabase-partitioning).







 February 2019 



 15 February 2019 

The stale option
: The stale option is deprecated and is replaced by stable and update, which allow controlling the two orthogonal behaviors that are caused by stale separately.



Table 3. Stale option replacement

 stable value Equivalent by using stable and update 

 false stable=false, update=true 
 ok stable=true, update=false 
 update_after stable=true, update=lazy 







 1 February 2019 

The following changes were made in build 7681:

Partition query
: Partition query bug fixes.







 January 2019 



 15 January 2019 

The following changes were made in build 7668:

New! Partition query
: This build introduces a new feature, [partition query](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-database-partitioningdatabase-partitioning).

limit
: Allow limit when you use POST for search.

View requests
: Previously, view requests that use a limit parameter greater than 268435456 would have the limit that is silently reduced to 268435456. Now, requests with the limit parameter greater than 268435456 are rejected with a 400 Bad Request error.





 1 January 2019
"name": "share-name1",
.
.
.
"latest_job": {
"status": "succeeded",
"status_reason": {
"code": "",
"message": "",
"more_info": ""
},
"type": "replication_failover"
}
}

For a replication split, when the replica share is being split from the source share, you can see a running status for latest_job in the response.

Example:

"latest_job": {
"status": "running",
"status_reason": {
"code": "",
"message": "",
"more_info": ""
},
"type": "replication_split"
},

A replication failover or split operation cannot happen if any other operation is being performed on the file share, such as expanding size. You can see a 409 error in the response that indicates the issue.

Example:

"errors": [
{
"code": "share_operation_pending",
"message": "An operation 'replication_failover' is pending on file share, request to 'replication_split' cannot be accepted.",
"more_info": "Before sending another request wait for the current operation to complete and try again."
}
],
"trace": "4634eee2-0a9b-43b7-b35e-8885cc258500"
This error occurs when an [instance policy](https://cloud.ibm.com/apidocs/key-protectset-instance-policies) is created.

The value of the metadata.collectionTotal field does not match the number of resources in the resources array.

The create instance policy request fails because the metadata.collectionTotal is 2, while 1 (one) resource was provided in the resources array.

 this request fails because the collectionTotal is 2 and there is 1 (one) resource
$ curl -X PUT "https://us-south.kms.cloud.ibm.com/api/v2/instance/policies?policy=dualAuthDelete" -H "authorization: Bearer $ACCESS_TOKEN" -H "bluemix-instance: $KP_INSTANCE_ID" -H "content-type: application/vnd.ibm.kms.policy+json" -d '{
"metadata": {
"collectionType": "application/vnd.ibm.kms.policy+json",
"collectionTotal": 2
},
"resources": [
{
"policy_type": "dualAuthDelete",
"policy_data": {
"enabled": false
}
}
]
}'
Show more



 JSON response 

{
"metadata": {
"collectionType": "application/vnd.ibm.kms.error+json",
"collectionTotal": 1
},
"resources":[
{
"errorMsg": "Bad Request: Instance policy could not be created. Please see reasons for more details.",
"reasons":
{
"code": "COLLECTION_TOTAL_MISMATCH_ERR",
"message": "Collection total does not match number of resources",
"status": 400,
"moreInfo": "https://cloud.ibm.com/apidocs/key-protect"
}
]
}
]
}
$ curl -X PUT "https://us-south.kms.cloud.ibm.com/api/v2/instance/policies?policy=allowedIP" -H "authorization: Bearer $ACCESS_TOKEN" -H "bluemix-instance: $KP_INSTANCE_ID" -H "content-type: application/vnd.ibm.kms.policy+json" -d '{
"metadata": {
"collectionType": "application/vnd.ibm.kms.policy+json",
"collectionTotal": 1
},
"resources": [
{
"policy_type": "allowedIP",
"policy_data": {
"enabled": true,
"attributes": {
"allowed_ip":
"65.128.226.252/24"
]
}
}
}
]
}'
Show more

Retrieving keys will fail because the request is outside the allowed range of IP addresses.

 this fails because the request is outside the allowed range of IP addresses
$ curl -X GET "https://us-south.kms.cloud.ibm.com/api/v2/keys" -H "authorization: Bearer $ACCESS_TOKEN"
-H "bluemix-instance: $KP_INSTANCE_ID"



 JSON response 

{
"metadata": {
"collectionType": "application/vnd.ibm.kms.error+json",
"collectionTotal": 1
},
"resources": [
{
"errorMsg": "Unauthorized: The user does not have access to the specified resource"
}
]
}









 Sorted by HTTP status code order 

These are the error messages, sorted the the HTTP status code.



 HTTP 400 - Bad Request 



* Collection total does not match number of resources - [details](https://cloud.ibm.com/docs/key-protect?topic=key-protect-error-messageserror-messages-collection-total-mismatch-err)
When you order a file share, your new storage is available to mount in a few minutes. You can view it in the Resource List and in the File Storage for Classic list.





 Authorizing host to the new File Storage for Classic 

"Authorized" hosts are hosts that were given access to a volume. Without host authorization, you can't access or use the storage from your system.



1. In the console, go to Classic Infrastructure![Classic icon](https://cloud.ibm.com/docs-content/v1/content/04e9937a86546143babfc65ea21fdd4ea2d12d13/icons/classic.svg) > Storage > File Storage for Classic.
2. Scroll to the File share that you want to mount, and click Actions![Actions icon](https://cloud.ibm.com/docs-content/v1/content/04e9937a86546143babfc65ea21fdd4ea2d12d13/icons/action-menu-icon.svg). Then, select Authorize Host.
3. Filter the available host list by selecting the device type, subnet, or IP address.

When the list is filtered by subnet, the subnets that are displayed are subscribed subnets in the same data center as the storage volume.
4. Select one or more hosts from the list and click Save.



When the host is authorized, connect the volume to your host.





 Migrating your data 



1. Connect to both your original and new File Storage for Classic volumes.



* [Mounting File Storage for Classic in CentOS](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-mountingCentOS)
* [Mounting File Storage for Classic on Red Hat Linux®](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-mountingLinux)
* [Mounting File Storage for Classic on Ubuntu](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-mountingUbuntu)
$ curl -X POST "https://us-south.kms.cloud.ibm.com/api/v2/keys/$KEY_ID/actions/setKeyForDeletion" -H "authorization: Bearer $ACCESS_TOKEN" -H "bluemix-instance: $KP_INSTANCE_ID" -H "content-type: application/vnd.ibm.kms.key_action+json"





 JSON response 

{
"metadata": {
"collectionType": "application/vnd.ibm.kms.error+json",
"collectionTotal": 1
},
"resources": [
{
"errorMsg": "Conflict: Action could not be performed on key. Please see reasons for more details.",
"reasons":
{
"code": "NOT_DUAL_AUTH_ERR",
"message":"The key is not dual auth enabled and cannot be set for deletion",
"status": 409,
"moreInfo": "https://cloud.ibm.com/apidocs/key-protect"
}
]
}
]
}

Remove an authorization for a key with a dual authorization policy.

 this request fails because the key DOES NOT have a dual authorization policy
$ curl -X POST "https://us-south.kms.cloud.ibm.com/api/v2/keys/$KEY_ID/actions/unsetKeyForDeletion" -H "authorization: Bearer $ACCESS_TOKEN" -H "bluemix-instance: $KP_INSTANCE_ID" -H "content-type: application/vnd.ibm.kms.key_action+json"





 JSON response 

{
"metadata": {
"collectionType": "application/vnd.ibm.kms.error+json",
"collectionTotal": 1
},
"resources": [
{
"errorMsg": "Conflict: Action could not be performed on key. Please see reasons for more details."
A string that is formatted as {"jws": "jws-format-string"} is returned that contains your tenant ID, the issuer of your JWS token, the timestamp of when the message was sent, a unique transaction ID, and the actual message information that includes your sender details and email body content.



Your extension point might look similar to the following example:

const sgMail = require('@sendgrid/mail');
const {promisify} = require('bluebird');
const request = promisify(require('request'));
const jwtVerify = promisify(require('jsonwebtoken').verify);
const jwtDecode = require('jsonwebtoken').decode;
const jwkToPem = require('jwk-to-pem');

async function obtainPublicKeys() {
// Your {{site.data.keyword.appid_short_notm}} instance tenant ID
const tenantId = '<tenantID>';

// Send request to {{site.data.keyword.appid_short_notm}}'s public keys endpoint
const keysOptions = {
method: 'GET',
url: https://<region>.appid.cloud.ibm.com/oauth/v4/$<tenantID>/publickeys
};
const keysResponse = await request(keysOptions);
return JSON.parse(keysResponse.body).keys;
}

async function verifySignature(keysArray, kid, jws) {
const keyJson = keysArray.find(key => key.kid === kid);
if (keyJson) {
const pem = jwkToPem(keyJson);
await jwtVerify(jws, pem);
return;
}
throw new Error ("Unable to verify signature");
}