vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Virtuozzo Containers 4 for Windows, by default, runs in compatibility mode.

Restoring backups from 3.5.1 on a Virtuozzo Containers 4 hardware node can also be performed by copying the full backup to the destination node, running vzbackupsync.exe and restoring the backup as normal.

Make sure that the same templates are installed on the new hardware node.





 Are containers isolated from each other and the host? 

Your containers are restricted from loading LKMs, performing a chroot(“../../../”) out of their own environment and don't share IPC Resources (semaphore sets and shared memory segments).

You have no security concerns with how Virtuozzo manages resources and isolates the processes. With a bridged network configuration, all containers in the same VLAN (on the same hardware node) can see each other's traffic. Using routed mode is highly suggested.





 Why can't I cache RedHat and SUSE OS templates in Virtuozzo? 

You can experience issues when you cache to RedHat and SUSE OS templates if you use Vitruozzo. These OS templates require extra licensing, which IBM Cloud doesn't provide. If you receive any of the following errors, you need to have your own accounts with the respective vendors and configure the corresponding variables within /etc/vztt/url.map (/etc/vztt/vztt.conf in Virtuozzo 3.)





 TIMESTAMP Click here to open/close the operation details.Update OS Template Cache Failed 
 TIMESTAMP Operation update with the Env(s) "virtuozzo00.softlayer.local" and package(s) .redhat-as4-x86_64 is started 
 TIMESTAMP Operation update with the Env(s) "virtuozzo00.softlayer.local" is finished with errors: Can not update packages: exec failed: Error: URL $RH_SERVER/download/mirrors/redhat-as4 contents undefined variable You can define this variable in /etc/vztt/url.map. . Failed
Set the nodes' role.

$ oc label node/10..177 node-role.kubernetes.io/sdi=""
$ oc label node/10..182 node-role.kubernetes.io/sdi=""
$ oc label node/10..185 node-role.kubernetes.io/sdi=""
3. Check the nodes.

oc get nodes

Example output:

NAME STATUS ROLES AGE VERSION
10..177 Ready master,sdi,worker 1d v1.21.8+ed4d8fd
10..182 Ready master,sdi,worker 1d v1.21.8+ed4d8fd
10..185 Ready master,sdi,worker 1d v1.21.8+ed4d8fd

Note that the sdirole has been added.







 Creating the related projects 

For deployment of SAP applications in cloud-based environments, SAP provides the Software Lifecycle Container Bridge 1.0 tool with the Maintenance Planner. In the following, we use the abbreviated tool name “SLC Bridge”. [Find more information on SAP's SLC Bridge here](https://help.sap.com/viewer/a8d90a56d61a49718ebcb5f65014bbe7/3.2.latest/en-US/0986e8da1d8f43379be9c7999f9ff280.html). Red Hat's SAP Data Intelligence (SDI) Observer, SLC Bridge and SDI runtime components require separate projects/namespaces for the related pods that will be deployed.

In the RHA, the sample project names (i.e. namespaces) are sdi, sdi-observer and sap-slcbridge. Following these naming conventions of the Red Hat article, create the related projects as follows.



1. create the projects

$ oc new-project sdi-observer
$ oc new-project sap-slcbridge
$ oc new-project sdi
When you try to add a lone symphony cluster with SMC, because of a time out issue you get the warning message. The message is a warning and does not impact adding lone symphony cluster with SMC.

 How to fix it 

This error won’t impact on adding a lone symphony cluster with SMC. Keep on addding other lone symphony clusters.





 What happen after provisioning SMC cluster, immediately if you try to logon as egosh user in secondary nodes of SMC? 

 What’s happening 

After provisioning SMC cluster, if you immediately try to logon on secondary nodes of SMC you see this message:

[root@hpc-secondary-smc] egosh user logon -u Admin -x Admin
bash: egosh command not found

 Why it’s happening 

It takes 10 min to sync primary host data of SMC to secondary nodes of SMC using rsync command.

 How to fix it 

Wait for 10 min after provisioning the SMC cluster, then try to login.
v1 [cURL](https://cloud.ibm.com/apidocs/assistant/assistant-v1updatevalue)[node](https://cloud.ibm.com/apidocs/assistant/assistant-v1?code=nodeupdatevalue)[java](https://cloud.ibm.com/apidocs/assistant/assistant-v1?code=javaupdatevalue)[python](https://cloud.ibm.com/apidocs/assistant/assistant-v1?code=pythonupdatevalue) 
 Delete entity value Delete a value from an entity. v1 [cURL](https://cloud.ibm.com/apidocs/assistant/assistant-v1deletevalue)[node](https://cloud.ibm.com/apidocs/assistant/assistant-v1?code=nodedeletevalue)[java](https://cloud.ibm.com/apidocs/assistant/assistant-v1?code=javadeletevalue)[python](https://cloud.ibm.com/apidocs/assistant/assistant-v1?code=pythondeletevalue) 
 List entity value synonyms List the synonyms for an entity value. v1 [cURL](https://cloud.ibm.com/apidocs/assistant/assistant-v1listsynonyms)[node](https://cloud.ibm.com/apidocs/assistant/assistant-v1?code=nodelistsynonyms)[java](https://cloud.ibm.com/apidocs/assistant/assistant-v1?code=javalistsynonyms)[python](https://cloud.ibm.com/apidocs/assistant/assistant-v1?code=pythonlistsynonyms) 
 Add entity value synonym Add a new synonym to an entity value.
Verify that the file system is still mounted on the NFS client node, and that the applications can still access the content.





 Test2 - Recovery procedure 

Log in to the IBM Cloud® Console and start the stopped instance. Wait until the cluster node is available again, then restart the cluster framework.

On the cluster node, run the following command.

pcs cluster start

Check the cluster status.

pcs status

Sample output:

 pcs status
Cluster name: SAP_NFS
Cluster Summary:
* Stack: corosync
* Current DC: cl-nfs-1 (version 2.0.5-9.el8_4.5-ba59be7122) - partition with quorum
* Last updated: Mon Mar 20 08:11:28 2023
* Last change: Mon Mar 20 07:56:25 2023 by hacluster via crmd on cl-nfs-1
* 2 nodes configured
* 9 resource instances configured

Node List:
* Online: [ cl-nfs-1 cl-nfs-2 ]

Full List of Resources:
* res_fence_ibm_powervs	(stonith:fence_ibm_powervs):	 Started cl-nfs-1
* Resource Group: nfsgroup:
* nfs_vg	(ocf::heartbeat:LVM-activate):	 Started cl-nfs-2
* nfs_fs1	(ocf::heartbeat:Filesystem):	 Started cl-nfs-2
* nfs_fs2	(ocf::heartbeat:Filesystem):	 Started cl-nfs-2
* nfs_fs3	(ocf::heartbeat:Filesystem):	 Started cl-nfs-2
* nfs_daemon	(ocf::heartbeat:nfsserver):	 Started cl-nfs-2
* nfs_export	(ocf::heartbeat:exportfs):	 Started cl-nfs-2
* nfs_ip
prod-dal10-pa215dcf5bbc0844a990fa6b0fcdbff286-w2 192.0.2.27 10.100.10.15 u3c.2x4 normal Ready
2. If a random NodePort was assigned, find out which one was assigned.

kubectl describe service <service_name>

Output

NAME: <service_name>
Namespace: default
Labels: run=<deployment_name>
Selector: run=<deployment_name>
Type: NodePort
IP: 10.10.10.8
Port: <unset> 8080/TCP
NodePort: <unset> 30872/TCP
Endpoints: 172.30.171.87:8080
Session Affinity: None
No events.

In this example, the NodePort is 30872.

If the Endpoints section displays <none>, check the <selectorkey> and <selectorvalue> that you use in the spec.selector section of the NodePort service. Ensure that it is the same as the key/value pair that you used in the spec.template.metadata.labels section of your deployment YAML.
3. Form the URL with one of the worker node IP addresses and the NodePort. Example: http://192.0.2.23:30872. For VPC clusters, you must be connected to the private network, such as through a VPN connection, to access the worker node private IP address and NodePort.
GPU device plug-in and installer 13fdc0d eb3a259 Updated images for [CVE-2019-3462](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-3462) and [CVE-2019-6486](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6486). 
 IBM Cloud Provider v1.12.4-118 v1.12.5-137 Updated to support the Kubernetes 1.12.5 release. Additionally, calicoctl version is updated to 3.3.1. Fixed unnecessary configuration updates to version 2.0 network load balancers on worker node status changes. 
 IBM Cloud File Storage for Classic plug-in 338 342 The File Storage for Classic plug-in is updated as follows:<br><br><br><br> * Supports dynamic provisioning with [volume topology-aware scheduling](https://cloud.ibm.com/docs/containers?topic=containers-file_storagefile-topology).<br> * Ignores persistent volume claim (PVC) delete errors if the storage is already deleted.<br> * Adds a failure message annotation to failed PVCs.<br> * Optimizes the storage provisioner controller's leader election and resync period settings, and increases the provisioning timeout from 30 minutes to 1 hour.<br> * Checks user permissions before starting the provisioning.<br><br><br> 
 Key Management Service provider 111 122 Added retry logic to avoid temporary failures when Kubernetes secrets are managed by IBM Key Protect for IBM Cloud. 
 Kubernetes v1.12.4 v1.12.5 See the [Kubernetes release notes](https://github.com/kubernetes/kubernetes/releases/tag/v1.12.5).
GPU device plug-in and installer 13fdc0d eb3a259 Updated images for [CVE-2019-3462](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-3462) and [CVE-2019-6486](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6486). 
 IBM Cloud Provider v1.11.6-180 v1.11.7-198 Updated to support the Kubernetes 1.11.7 release. Additionally, calicoctl version is updated to 3.3.1. Fixed unnecessary configuration updates to version 2.0 network load balancers on worker node status changes. 
 IBM Cloud File Storage for Classic plug-in 338 342 The file storage plug-in is updated as follows:<br><br><br><br> * Supports dynamic provisioning with [volume topology-aware scheduling](https://cloud.ibm.com/docs/containers?topic=containers-file_storagefile-topology).<br> * Ignores persistent volume claim (PVC) delete errors if the storage is already deleted.<br> * Adds a failure message annotation to failed PVCs.<br> * Optimizes the storage provisioner controller's leader election and resync period settings, and increases the provisioning timeout from 30 minutes to 1 hour.<br> * Checks user permissions before starting the provisioning.<br><br><br> 
 Key Management Service provider 111 122 Added retry logic to avoid temporary failures when Kubernetes secrets are managed by IBM Key Protect for IBM Cloud. 
 Kubernetes v1.11.6 v1.11.7 See the [Kubernetes release notes](https://github.com/kubernetes/kubernetes/releases/tag/v1.11.7).
Create a NodePort for your app. A NodePort in the range of 30000 - 32767 and an internal cluster IP address is assigned to your app.

oc expose deployment <deployment_name> --type=NodePort --name=<nodeport_svc_name>
2. Get the NodePort that was assigned to your app.

oc describe svc <nodeport_svc_name>
3. Get the Hostname for your cluster in the format <cluster_name>-<random_hash>-0000.upi.containers.appdomain.cloud.

ibmcloud oc nlb-dns ls --cluster <cluster_name_or_ID>
4. Access your app by using your cluster's subdomain and the NodePort in the format <cluster_name>-<random_hash>-0000.upi.containers.appdomain.cloud:<nodeport>. Note that if your hosts have private network connectivity only, you must be connected to the hosts' private network, such as through VPN access.
5. Optional: If you don't want to access the NodePort directly, or if you must expose your apps on a specific port such as 443, you can set up your own third-party, layer 4 load balancer that is connected to your hosts' private network and forwards traffic to the NodePort. For example, you might deploy a load balancer from your hosts' cloud provider, or deploy an F5 load balancer to your on-premises network. The load balancer must be able to forward TCP and UDP traffic for ports 30000 - 32767.







 Exposing apps with routes and Link endpoints for traffic from IBM Cloud 

If you want to access an app in your Satellite cluster from a resource in IBM Cloud over the private network, you can use your private Ingress controller to create a private route for your app. Then, you can create a Link endpoint of type location for the route, which is accessible only from within the IBM Cloud private network.



1.
If your app workload requires other IBM Cloud services that support private cloud service endpoints, your worker nodes can automatically, securely communicate with these services over the private VPC network.





 External communication to apps that run on worker nodes 

After you test your app, you can expose it to the private network by creating a private Kubernetes LoadBalancer service or using the default private Ingress application load balancers (ALBs). The VPC load balancer that is automatically created in your VPC outside of your cluster when you use one of these services routes traffic to your app. Note that the VPC load balancer exposes your app to the private network only so that any on-premises system with a connection to the VPC subnet can access the app. You can improve the security of your cluster and control public traffic apps by modifying the default VPC security group for your cluster. Security groups consist of rules that define which inbound traffic is permitted for your worker nodes.

Ready to get started with a cluster for this scenario? After you plan your [high availability](https://cloud.ibm.com/docs/containers?topic=containers-ha_clusters) and [worker node](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodes) setups, see [Creating VPC clusters](https://cloud.ibm.com/docs/containers?topic=containers-clusters).
You should consider this step only in emergencies, such as when a disaster has disrupted a majority of cluster nodes. This can be accomplished this with a PowerShell script, to force an online node to assume the primary role without a majority of votes.



Failovers are not caused by database issues such as a database becoming suspect due to a loss of a data file or corruption of a transaction log.





 Other types of availability groups 

The following availability groups are not used in this deployment pattern, but may be of interest to solutioners wanting to adapt or extend this deployment pattern:



* Basic availability groups - A limited version of availability groups and are supported only on SQL Server Standard edition. The single secondary replica cannot be readable or backed up and each basic availability group can support only two replicas, but multiple basic availability groups can be configured per server. Basic availability groups allow for many of the same features of availability groups including synchronous or asynchronous replication, manual or automatic failovers.
* Distributed availability groups - This allows an availability group to treat another availability group to act as a secondary replica. The read-only secondary replicas can be globally dispersed, offloading workloads to regional read-only secondary replicas. The two availability groups, each with their own listener, do not need to be in same network or WSFC. This allows for geographically remote HA and DR across multi-site deployments. With distributed availability groups, a WSFC does not need to span across regions. There is no automatic failover between the primary availability group and the secondary availability group. The availability group that is not primary can only serve read-only queries, but does have a primary replica itself. The primary replica in the secondary availability group is charged with replicating transactions to the other secondary replicas in the secondary availability group. This architecture is useful for OS and SQL Server version upgrades as you can have different versions of Windows Server in each availability group. Although each availability group in a distributed scenario has its own listener, the distributed availability group as a whole does not. Applications, perhaps with the aid of DNS aliases, will connect to each availability group directly after a failover to take advantage of readable secondary replicas.









 Distributed Network Names
Memory usage with Node.js runtime actions 

  What’s happening 

In the case where an action consumes more memory than requested, the action is terminated and the following log information is displayed:

2019-10-22T10:00:50.509Z  stderr: Killed
2019-10-22T10:00:50.510Z  stderr: The action did not initialize or run as expected. Log data might be missing.

  Why it’s happening 

When Cloud Functions runs successive invocations of the same action, the optimizations that are performed by Cloud Functions might consume more memory than expected to improve run times.

For example, when Cloud Functions runs actions, Linux containers are used for the processes. To speed up the process, new containers are not created each time that your action runs ("cold"), but instead, existing containers that ran your action before ("warm") are reused. So when your action completes, the container "freezes" to pause all processes and then "wakes" when your action is rerun.

This approach affects garbage collection. When you run a Node.js action, garbage is created on the heap. This garbage is accumulating over each warm reuse of the action process. However, because the Node.js process pauses between invocations, garbage collection does not run reliably.

  How to fix it 

Invoke Node.js garbage collection explicitly from within your action code by adding the option --expose-gc.

For example, use code similar to the following example code in your action:

try {
if (global.gc) {
console.log("About to run garbage collection.");
global.gc();
console.log("Completed running garbage collection.");
} else {
console.log("Garbage collection not available.");
}
} catch (e) {
console.log("Garbage collection cannot be started: " + e);
}
const gateway = new Gateway()

The FileSystemWallet class is used to load the wallet you created in the previous step. Edit the following line if you changed the location of the wallet on your file system.

const wallet = new FileSystemWallet('../identity/user/isabella/wallet');

After you import your wallet, use the following code to pass your connection profile and wallet to the new gateway. You need to make the following Edits to the code so it resembles the code snippet below. The lines that print logs have been removed for brevity.



* Update the userName to match the value that you selected for your identityLabel in enrollUser.js.
* Update the discovery options to take advantage of service discovery on your network. Set discovery: { enabled: true, asLocalhost: false, strategy: DefaultQueryHandlerStrategies.MSPID_SCOPE_ROUND_ROBIN }.
* Update the section importing your connection profile. The console connection profile is in JSON format rather than a YAML file used by the sample.



const userName = 'user1';

// Load connection profile; will be used to locate a gateway
const ccpPath = path.resolve(__dirname, '../gateway/connection.json');
const ccpJSON = fs.readFileSync(ccpPath, 'utf8');
const connectionProfile = JSON.parse(ccpJSON);

// Set connection options; identity and wallet
let connectionOptions = {
identity: userName,
wallet: wallet,
discovery: { enabled: true, asLocalhost: false, strategy: DefaultQueryHandlerStrategies.MSPID_SCOPE_ROUND_ROBIN }
};

await gateway.connect(connectionProfile, connectionOptions);
Show more

This code snippet uses the gateway to open gRPC connections to the peer and orderer nodes, and interact with your network.



 Enabling service discovery
node.session.auth.username = <Username-value-from-Portal>
node.session.auth.password = <Password-value-from-Portal>
discovery.sendtargets.auth.authmethod = CHAP
discovery.sendtargets.auth.username = <Username-value-from-Portal>
discovery.sendtargets.auth.password = <Password-value-from-Portal>

Leave the other CHAP settings commented. IBM Cloud® storage uses only one-way authentication. Do not enable Mutual CHAP.





 Step 5: Discover the storage device and login 

The iscsiadm utility is a command-line tool aids the discovery and login to iSCSI targets, plus access and management of the open-iscsi database. For more information, see the [iscsiadm(8) man page](https://linux.die.net/man/8/iscsiadm). In this step, discover the device by using the Target IP address that was obtained from the IBM Cloud® console.



1. Run the discovery against the iSCSI array.

iscsiadm -m discovery -t sendtargets -p <ip-value-from-IBM-Cloud-console>

If the IP information and access details are displayed, then the discovery is successful.
2. Log in to the iSCSI array.

iscsiadm -m node --login







 Step 6: Verifying configuration 



1. Validate that the iSCSI session is established.

iscsiadm -m session -o show
2. Validate that multiple paths exist.

multipath -l

This command reports the paths. If it is configured correctly, then each volume has a single group, with a number of paths equal to the number of iSCSI sessions. It's possible to attach Block Storage for Classic with only a single path, but it is important that Connections are established on both paths to ensure no disruption of service.
v1 [cURL](https://cloud.ibm.com/apidocs/assistant/assistant-v1getsynonym)[node](https://cloud.ibm.com/apidocs/assistant/assistant-v1?code=nodegetsynonym)[java](https://cloud.ibm.com/apidocs/assistant/assistant-v1?code=javagetsynonym)[python](https://cloud.ibm.com/apidocs/assistant/assistant-v1?code=pythongetsynonym) 
 Update entity value synonym Update an existing entity value synonym with new text. v1 [cURL](https://cloud.ibm.com/apidocs/assistant/assistant-v1updatesynonym)[node](https://cloud.ibm.com/apidocs/assistant/assistant-v1?code=nodeupdatesynonym)[java](https://cloud.ibm.com/apidocs/assistant/assistant-v1?code=javaupdatesynonym)[python](https://cloud.ibm.com/apidocs/assistant/assistant-v1?code=pythonupdatesynonym) 
 Delete entity value synonym Delete a synonym from an entity value. v1 [cURL](https://cloud.ibm.com/apidocs/assistant/assistant-v1deletesynonym)[node](https://cloud.ibm.com/apidocs/assistant/assistant-v1?code=nodedeletesynonym)[java](https://cloud.ibm.com/apidocs/assistant/assistant-v1?code=javadeletesynonym)[python](https://cloud.ibm.com/apidocs/assistant/assistant-v1?code=pythondeletesynonym) 
 List dialog nodes List the dialog nodes for a workspace.
* VPC: Replace the worker node.

ibmcloud oc worker replace -c <cluster_name_or_ID> --worker <worker_ID> --update



4. Wait for the worker node to finish restarting. If the worker node enters a healthy state, the issue is likely caused by a workload.
5. Schedule one workload at a time onto the worker node to see which workload causes the issue. To schedule the workloads, add the following toleration.

tolerations:
- effect: NoExecute
key: ibm-cloud-debug-isolate-customer-workload
operator: Exists
6. After you identify the workload that causes the issue, continue with [Debugging app deployments](https://cloud.ibm.com/docs/openshift?topic=openshift-debug_apps).