vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Typically, a performant and effective way to employ this feature is by using it only on specific databases or users that must have the highest degree of data durability available.





 Application-level High-Availability 

Applications that communicate over networks and cloud services are subject to transient connection failures. You want to design your applications to retry connections when errors are caused by a temporary loss in connectivity to your deployment or to IBM Cloud.

Because Databases for PostgreSQL is a managed service, regular updates and database maintenance occurs as part of normal operations. This can occasionally cause short intervals where your database is unavailable. It can also cause the database to trigger a graceful fail-over, retry, and reconnect. It takes a short time for the database to determine which member is a replica and which is the leader, so you might also see a short connection interruption. Failovers generally take less than 30 seconds.

Your applications have to be designed to handle temporary interruptions to the database, implement error handling for failed database commands, and implement retry logic to recover from a temporary interruption.

Several minutes of database unavailability or connection interruption are not expected. Open a [support case](https://cloud.ibm.com/unifiedsupport/cases/add) with details if you have time periods longer than a minute with no connectivity so we can investigate.





 Connection Limits 

Databases for PostgreSQL sets the maximum number of connections to your PostgreSQL database to 115. 15 connections are reserved for the superuser to maintain the state and integrity of your database, and 100 connections are available for you and your applications. After the connection limit is reached, any attempts at starting a new connection results in an error. To prevent overwhelming your deployment with connections, use connection pooling, or scale your deployment and increase its connection limit. For more information, see the [Managing PostgreSQL Connections](https://cloud.ibm.com/docs/databases-for-postgresql?topic=databases-for-postgresql-managing-connections) page.





 High availability, disaster recovery, and SLA resources
Feature Connected behavior Disconnected behavior Maximum disconnection tolerance 

 Application, audit and access logging with IBM Cloud Activity Tracker -- -- -- 
 Application monitoring with IBM Cloud Monitoring -- -- -- 
 Application logging using other provider You can use third-party logging tools. No impact. Equal to the accessTokenMaxAgeSeconds from last authentication 
 System/Kubernetes logging using other provider You can use third-party logging tools. No impact. Equal to the accessTokenMaxAgeSeconds from last authentication 
 Alerting rules and paging for metrics You can set up alerts in IBM Cloud Monitoring. Alerts are not triggered. Zero 







 Config management disconnected usage 



Disconnected config management

 Feature Connected behavior Disconnected behavior Maximum disconnection tolerance 

 Satellite Config You can create and manage configurations by using Satellite Config. You cannot create and manage configurations by using Satellite Config. Zero 
 Satellite Storage Config You can create and manage configurations by using Satellite Storage Config. You cannot create and manage configurations by using Satellite Storage Config. Zero 







 Networking disconnected usage 



Disconnected network and service mesh management

 Feature Connected behavior Disconnected behavior Maximum disconnection tolerance 

 Deploying or updating policies Satellite Service Mesh You can deploy or update policies by using the CLI and console. You can use kubectl to deploy and update policies. Equal to the accessTokenMaxAgeSeconds from last authentication
kubectl apply -f "https://config.satellite.cloud.ibm.com/api/install/razeedeploy-job?orgKey=<orgApiKey>&args=--clustersubscription=<number>&args=--featureflagsetld=<number>&args=--mustachetemplate=<number>&args=--managedset=<number>&args=--remoteresources<number>&args=--remoteresource=<number>&args=--watch-keeper=<number>"
2. Log in to your cluster. If you are not connected to your location host network, include the --endpoint link option. For more login options, see [Accessing Red Hat OpenShift clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).

ibmcloud oc cluster config -c <cluster_name_or_ID> --admin [--endpoint link]
3. Run the kubectl command that you previously retrieved.



2. Grant Satellite Config permissions in your cluster to manage Kubernetes resources. The following command grants cluster-admin permissions for the entire cluster. For more options, see [Granting Satellite Config access to your clusters](https://cloud.ibm.com/docs/satellite?topic=satellite-setup-clusters-satconfig).

kubectl create clusterrolebinding razee-cluster-admin --clusterrole=razee-cluster-admin --serviceaccount=razeedeploy:razee-viewer --serviceaccount=razeedeploy:razee-editor --serviceaccount=razeedeploy:razee-satcon
Edit the prefix value and specifiy a new prefix.





 Invalid index 

During Terraform apply, you get an error similar to this:

Error: Invalid index
│
│ on providers.tf line 3, in provider "ibm":
│ 3: region = local.regions[var.zone]
│ ├────────────────
│ │ local.regions is object with 27 attributes
│ │ var.zone is "us-east"

You specified a zone that was not vaild. For example, you entered us-east for zone but you needed to enter us-east-1, us-east-2, or us-east-3.





 Error fetching Keys An error occurred while performing the 'authenticate' step 

You get a message similar to:

Error: [ERROR] Error fetching Keys An error occurred while performing the 'authenticate' step: {"errorCode":"BXNIM0415E","errorMessage":"Provided API key could not be found","context":{"requestId":"aDJwNTQ-fec49a18af674b77a356764b2c633520","requestType":"incoming.Identity_Token","userAgent":"Go-http-client/1.1","url":"https://iam.cloud.ibm.com","instanceId":"iamid-7.7-13974-e612b1c-84749569f-h2p54","threadId":"37adb","host":"iamid-7.7-13974-e612b1c-84749569f-h2p54","startTime":"12.07.2022 14:47:03:629 UTC","endTime":"12.07.2022 14:47:03:699 UTC","elapsedTime":"70","locale":"en_US","clusterName":"iam-id-prod-eu-gb-lon05"}}
│ {
Why does my app connection fail? 

  What’s happening 

Your application connects to another service, such as a database. When your app runs, you notice that the connection ends unexpected and you receive an error similar to the following example.

[IBM] SQL30081N  A communication error has been detected. Communication protocol being used: "SSL".

  Why it’s happening 

By default, your app times out after 5 minutes. If it does not receive any updates from the connection within this time, then your app ends the connection. For more information, see [Application defaults and limits](https://cloud.ibm.com/docs/codeengine?topic=codeengine-limitslimits_application).

  How to fix it 

You can resolve this issue by changing the timeout value for your app. If your app requires a connection time that is longer than 10 minutes, configure your app to include a a heartbeat connection to the other service, which keeps your connection active. You can also run a Code Engine job and then return the output to your app. For more information about jobs, see [Working with jobs and job runs](https://cloud.ibm.com/docs/codeengine?topic=codeengine-job-plan).



  Updating your app timeout value from the console 

To update your app from the console,



1.  Open the [Code Engine console](https://cloud.ibm.com/codeengine/overview).
2.  Click the project that contains your app and then click the app to open the Overview page.
3.  Click Edit and create a new revision.
4.  Select Runtime and then change the value in the Request timeout (seconds) field. The maximum value is 600 seconds (10 minutes).
5.  Click Save and create.







  Updating your app timeout value with the CLI 

To update your app with the CLI, run the [app update](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-application-update) command with the --request-timeout option set to the new timeout value. The maximum value is 600 seconds (10 minutes).

After your app is updated, Code Engine creates a revision of your app. When the app revision reaches a Ready state, all traffic is routed to this new instance.
Updating CDN configuration details 

After your CDN is running, you can update CDN configuration details. Follow these steps.



1.  On the CDN page, select your CDN, which takes you to the Overview page.
2.  Select the Settings tab. Your CDN configuration details are displayed.

You only see SSL Certificate if your CDN was configured with HTTPS.

For Server, the following fields can be changed:



*  Host header
*  Origin server address
*  HTTP/HTTPS Port
*  Serve Stale Content
*  Respect Headers
*  Optimization options
*  Cache-query



For Object Storage, the following fields can be changed:



*  Host header
*  Endpoint
*  Bucket name
*  HTTPS Port
*  Allowed file extensions
*  Serve Stale Content
*  Respect Headers
*  Optimization options
*  Cache-query



3.  Update the Origin or Other Options details if needed, then click the Save button in the lower right corner to update your CDN configuration details.
If the two IP addresses match the internal IP addresses of your VM, the cloud-init configuration ran successfully.

Verifying the cloud-init configuration:

Work with TCP/IP Interfaces
System: KCW73A
Type options, press Enter.
1=Add 2=Change 4=Remove 5=Display 9=Start 10=End

Internet Subnet Line Line
Opt Address Mask Description Type
___ 10.1.1.5 255.255.255.192 CLOUDINIT1 ELAN
___ 127.0.0.1 255.0.0.0 LOOPBACK NONE
___ 192.168.128.138 255.255.255.248 CLOUDINIT2 ELAN

Bottom
F3=Exit F5=Refresh F6 Print list F11-Display interface status
F12=Cancel F17=Top F18=Bottom
Show more

If you do not see the external IP address in the Work with TCP/IP Interfaces window, wait approximately 10 minutes, open another terminal and ping the external IP address. The external address must match what is shown in the Power Systems Virtual Server user interface within your instance's Server details pane. Contact support or delete and reprovision your IBM i VM if the ping doesn't return anything.

Lastly, enter the WRKLICINF command and F11 to display the usage information to verify that the cloud-init injected the license keys correctly. After you verify your network and license key configuration, you can initial program load (IPL) the LPAR.

If License Keys for the operating system or any IBM i Licensed Program Products (LPP) have not been applied, follow instructions in the [PowerVS license key issues](https://www.ibm.com/support/pages/mustgather-powervs-license-key-issues) document.

If this is an upgraded system that contained License Keys before, please allow a weekend (Saturday-Sunday) to process the updated keys before collecting the [PowerVS license key issues](https://www.ibm.com/support/pages/mustgather-powervs-license-key-issues) information.
How to fix it 

Try the following solutions to resolve your problem.



1. Code Engine apps are designed to run without exiting. If your app code includes an exit, then consider [running your code as a job](https://cloud.ibm.com/docs/codeengine?topic=codeengine-job-plan) instead.
2. Check for messages that might help you determine the cause. If you set up logging for Code Engine, your log files might contain messages. For more information about logging, see [Viewing logs](https://cloud.ibm.com/docs/codeengine?topic=codeengine-view-logs). Your app must follow [12-factor app methodology](https://12factor.net/). For example, if the underlying structure of Code Engine that your app is running on requires an update, then a new instance of your app is created on the updated infrastructure. When your new app instance is marked as Ready, Code Engine routes traffic to it. Your old app then receives a SIGTERM message, allowing time for it to shut down safely. If it does not shut down, then Code Engine sends a SIGKILL message and your old app instance is destroyed, which can cause data to be lost.
3. Re-create the image in Container Registry and then deploy another instance of your app. Then, check your [image retention policy](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_retention) in Container Registry so that images that are used by active revisions are not deleted. If you are using toolchain templates for Code Engine, you can also add logic to your pipeline definition to delete unused versions of your image only after a working version is deployed.
4. Create a new revision for your app by [updating your application](https://cloud.ibm.com/docs/codeengine?topic=codeengine-update-app). If an image is pushed with same tag, then you must update your application to create a new revision that uses this updated image.
Updating a server to use a local WSUS server 

If your server that is running Windows® was provisioned with a cloud-init enabled image, you might want to manually update the Windows registry to use local IBM Cloud® Windows Server Update Services (WSUS) servers, rather than the default Microsoft® WSUS servers.

If you order a server with a Windows Server operating system without any add-ons, such as more software, post-provisioning scripts, or monitoring, it is likely that your server is provisioned with a cloud-init image. With cloud-init provisions, the WSUS server defaults to the Microsoft WSUS server.

If you want to update the server to use the IBM Cloud local WSUS server, use the following .reg file after you provision the server. Make the following changes before you use this file.



* Change wsusdal0102 to the local data center where your server is provisioned.
* The line that includes DoNotConnectToWindowsUpdateInternetLocations forces the server to use the WSUS server. You can leave it out if want to check against Windows Update and WSUS.



Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate]
"ElevateNonAdmins"=dword:00000000
"WUServer"="http://wsusdal0102.service.softlayer.com"
"WUStatusServer"="http://wsusdal0102.service.softlayer.com"
"DoNotConnectToWindowsUpdateInternetLocations"=dword:00000001

[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU]
"AUOptions"=dword:00000005
"NoAutoRebootWithLoggedonUsers"=dword:00000001
"NoAutoUpdate"=dword:00000000
"RebootReLaunchTimeout"=dword:000000f0
Change log for worker node fix pack 1.9.10_1531, released 26 October 2018 

The following table shows the changes that are in the worker node fix pack 1.9.10_1531.



Table 1. Changes since version 1.9.10_1530

 Component Previous Current Description 

 OS interrupt handling N/A N/A Replaced the interrupt request (IRQ) system daemon with a more performant interrupt handler. 







 Change log for master fix pack 1.9.10_1530 released 15 October 2018 

The following table shows the changes that are in the worker node fix pack 1.9.10_1530.



Table 1. Changes since version 1.9.10_1527

 Component Previous Current Description 

 Cluster update N/A N/A Fixed problem with updating cluster add-ons when the master is updated from an unsupported version. 







 Change log for worker node fix pack 1.9.10_1528, released 10 October 2018 

The following table shows the changes that are in the worker node fix pack 1.9.10_1528.



Table 1. Changes since version 1.9.10_1527

 Component Previous Current Description 

 Kernel 4.4.0-133 4.4.0-137 Updated worker node images with kernel update for [CVE-2018-14633, CVE-2018-17182](https://changelogs.ubuntu.com/changelogs/pool/main/l/linux/linux_4.4.0-137.163/changelog) 
 Inactive session timeout N/A N/A Set the inactive session timeout to 5 minutes for compliance reasons. 







 Change log for 1.9.10_1527, released 2 October 2018 

The following table shows the changes that are in patch 1.9.10_1527.



Table 1. Changes since version 1.9.10_1523

 Component Previous Current Description 

 IBM Cloud Provider v1.9.10-192 v1.9.10-219 Updated the documentation link in load balancer error messages.
public static void updateMetadataPut(String bucketName, String itemName, String key, String value) throws IOException {
System.out.printf("Updating metadata for item: %sn", itemName);

//retrieve the existing item to reload the contents
S3Object item = _cos.getObject(new GetObjectRequest(bucketName, itemName));
S3ObjectInputStream itemContents = item.getObjectContent();

//read the contents of the item in order to set the content length and create a copy
ByteArrayOutputStream output = new ByteArrayOutputStream();
int b;
while ((b = itemContents.read()) != -1) {
output.write(b);
}

int contentLength = output.size();
InputStream itemCopy = new ByteArrayInputStream(output.toByteArray());

//set the new metadata
HashMap<String, String> userMetadata = new HashMap<String, String>();
userMetadata.put(key, value);

ObjectMetadata metadata = new ObjectMetadata();
metadata.setContentLength(contentLength);
metadata.setUserMetadata(userMetadata);

PutObjectRequest req = new PutObjectRequest(bucketName, itemName, itemCopy, metadata);

_cos.putObject(req);

System.out.printf("Updated metadata for item %s from bucket %sn", itemName, bucketName);
}
Show more





 Using COPY to update metadata 

public static void updateMetadataCopy(String bucketName, String itemName, String key, String value) {
System.out.printf("Updating metadata for item: %sn", itemName);

//set the new metadata
* UI
* CLI
* API







 Updating custom resolver forwarding rules 

You can update custom resolver forwarding rules in IBM Cloud® DNS Services by using the UI, CLI, or API.

Changing the Default rule might cause issues with DNS query resolution in VPCs that have virtual private endpoints, IKS clusters, ROKS clusters, or defined private DNS zones.



 Updating custom resolver forwarding rules using the UI 

You can edit custom resolver forwarding rules from the custom resolver details page.

To edit a forwarding rule:



1. Click the Forwarding rules tab.
2. Click the overflow menu next to the rule you want to edit.
3. In the panel that appears, change the match conditions, forwarding IP addresses, or description.
4. Click Save to commit your changes, or click Cancel to discard them.

You cannot edit the rule type. If you require a different rule type, create a new rule.







 Updating custom resolver forwarding rules using the CLI 

To update a custom resolver forwarding rule using the CLI, run the following command:

ibmcloud dns custom-resolver-forwarding-rule-update RESOLVER_ID RULE_ID [--match HOSTNAME] [--dns-svcs IPs] [--description DESCRIPTION] [-i, --instance INSTANCE] [--output FORMAT]

Where:



* RESOLVER_ID is the ID of custom resolver.
* RULE_ID is the ID of custom resolver forwarding rule.
* -d, --description is the descriptive text of the custom resolver forwarding rule.
* -match is the matching zone or hostname.
* --dns-svcs is the upstream DNS servers to be forwarded to.
* -i, --instance is the instance name or ID. If this is not set, the context instance specified by dns instance-target INSTANCE is used instead.
* --output specifies output format. Currently, JSON is the only supported format.







 Updating custom resolver forwarding rules using the API
When updating a monitor, the existing headers are replaced by the ones that you specify. To delete all existing headers, specify the option with an empty value (--header "").

--expected-body <expected-body>
: When type is HTTP or HTTPS: A case-insensitive substring that the health check looks for in the response body. If this string is not found, the IP is considered unhealthy.

--expected-codes <expected-codes>
: When type is HTTP or HTTPS: HTTP codes that the health check looks for in the response. If the HTTP code is not found, the IP is considered unhealthy. Default: 2xx.

--allows-insecure <true>
: When type is HTTP or HTTPS: Set to true to not validate the certificate.

--follows-redirects <true>
: When type is HTTP or HTTPS: Set to true to follow any redirects that are returned by the IP.

Example command

ibmcloud ks nlb-dns monitor configure --cluster mycluster --nlb-host mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud --enable --description "Login page monitor" --type HTTPS --method GET --path / --timeout 5 --retries 2 --interval 60 --header Host=example.com --header Origin=https://akamai.com --expected-body "healthy" --expected-codes 2xx --follows-redirects true
3. Verify that the health check monitor is configured with the correct settings.

ibmcloud ks nlb-dns monitor get --cluster <cluster_name_or_id> --nlb-host <host_name>

Example output

Created On: 2019-04-24 09:01:59.781392 +0000 UTC
Modified On: 2020-02-26 15:39:05.273217 +0000 UTC
Type: https
Why can't I upgrade to version 1.12 of the managed Istio add-on? 

Virtual Private Cloud

Classic infrastructure

  What’s happening 

When you upgrade your managed Istio components from version 1.11 to version 1.12, the upgrade does not complete.

When you [check the status](https://cloud.ibm.com/docs/containers?topic=containers-debug_addons) of the Istio add-on, the HEALTH STATUS remains set to (1.11 --> 1.12).

Name    Version   Health State   Health Status
istio   1.12      updating       (1.11 --> 1.12)

Additionally, when you check the logs for the addon-istio-operator pod by running kubectl logs -n ibm-operators -l name=managed-istio-operator, you see the following error messages.

Error [IST0139] (MutatingWebhookConfiguration istio-sidecar-injector) Webhook overlaps with others: [istio-sidecar-injector/namespace.sidecar-injector.istio.io]. This may cause injection to occur twice.
Error [IST0139] (MutatingWebhookConfiguration istio-sidecar-injector) Webhook overlaps with others: [istio-sidecar-injector/sidecar-injector.istio.io]. This may cause injection to occur twice.

  Why it’s happening 

If the Istio add-on instance you are upgrading was provisioned at version 1.10 or earlier, there are webhook issues that must be resolved before you can upgrade to version 1.12.

  How to fix it 

To resolve the webhook errors and continue the version upgrade, follow the instructions in step 4 of [Updating the minor version of the Istio add-on](https://cloud.ibm.com/docs/containers?topic=containers-istioistio_minor).

Wait for the upgrade to proceed. Then, [check the Istio health status](https://cloud.ibm.com/docs/containers?topic=containers-debug_addons) to verify that the add-on is functioning normally.

Name    Version   Health State   Health Status
istio   1.12      normal         Addon Ready
* [Checking and updating the Object Storage plug-in](https://cloud.ibm.com/docs/containers?topic=containers-debug_storage_cosdebug_storage_cos_plugin)
* [Checking driver logs and the driver version installed](https://cloud.ibm.com/docs/containers?topic=containers-debug_storage_cosdebug-storage-logs)
* [Updating the Helm chart](https://cloud.ibm.com/docs/containers?topic=containers-debug_storage_cosdebug-helm-update)



[Why can't my PVC access an existing bucket?](https://cloud.ibm.com/docs/containers?topic=containers-cos_access_bucket_failscos_access_bucket_fails)

[Why does installing the Object storage Helm plug-in fail?](https://cloud.ibm.com/docs/containers?topic=containers-cos_helm_failscos_helm_fails)

[Why can't non-root users access files?](https://cloud.ibm.com/docs/containers?topic=containers-cos_nonroot_accesscos_nonroot_access)



* [Verifying that the permissions for your files are updated](https://cloud.ibm.com/docs/containers?topic=containers-cos_nonroot_accessverifying_file_permission_update)



[Why does my app pod fail with an Operation not permitted error?](https://cloud.ibm.com/docs/containers?topic=containers-cos_operation_not_permittedcos_operation_not_permitted)

[Why can't the ownership of the mount path be changed?](https://cloud.ibm.com/docs/containers?topic=containers-cos_mountpath_errorcos_mountpath_error)

[Why does installing the IBM Cloud Object Storage plug-in fail?]