vania-janet/multiturn-rag-retrieval-data huggingface dataset:
TIMESTAMP Operation update with the Env(s) "virtuozzo01.softlayer.local" is finished with errors: Can not update packages: exec failed: Error: URL $RH_SERVER/download/mirrors/redhat-el5 contents undefined variable You can define this variable in /etc/vztt/url.map. . Failed 
 TIMESTAMP Click here to open/close the operation details.Update OS Template Cache Failed <br> <br>Oct 29, 2008 01:16:56 PM Operation update with the Env(s) "virtuozzo01.softlayer.local" and package(s) .sles-10-x86_64 is started 
 TIMESTAMP Operation update with the Env(s) "virtuozzo01.softlayer.local" is finished with errors: Can not update packages: exec failed: Error: URL $SLES_SERVER/download/mirrors/suse-es10 contents undefined variable . Failed 
 TIMESTAMP Completing the process Failed 







 Why can I ping my ServiceVE but cannot log in to via SSH (PIM/PMC)? 

Make sure that the host node doesn't have any IP addresses assigned other than the IP addresses that are listed in the Portal (1 public IP and 1 private IP [located in 10.0.0.0/8]).

If you have any range files that are configured on the host node, then you need to remove these files and restart networking.

[root@virtuozzo ] mv –vi /etc/sysconfig/network-scripts/eth[0-9]-range[0-9] /.sl-orig-configs/

[root@virtuozzo ] /sbin/service network restart

vzcp isn't started within the Service VE. Start vzcp within the Service VE from the hardware node.

[root@virtuozzo ] vzctl exec2 1 service vzcp status

vzcp is stopped

[root@virtuozzo ] vzctl exec2 1 service vzcp start

Starting vzcpd: [ OK ]

Starting vzcp: [ OK ]
Initiate a manual data synchronization request by running the following curl command.

$ curl -X POST "https://api.<region>.hs-crypto.cloud.ibm.com:<port>/api/v2/keys/<key_ID>/actions/sync" -H "authorization: Bearer <IAM_token>" -H "bluemix-instance: <instance_ID>"

Replace the variables in the example request according to the following table.



Table 1. Describes the variables needed to initiate a renotification of a key lifecycle event

 Variable Description 

 region Required. The region abbreviation, such as us-south, that represents the geographic area where your Hyper Protect Crypto Services instance resides. For more information, see [Regional service endpoints](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-regionsservice-endpoints). 
 key_ID Required. The identifier for the root key that is associated with the cloud resources that you want to view. For more information, see [View Keys](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-view-keys). 
 IAM_token Required. Your IBM Cloud access token. Include the full contents of the IAM token, including the Bearer value, in the curl request. For more information, see [Retrieving an access token](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-retrieve-access-token). 
 instance_ID Required. The unique identifier that is assigned to your Hyper Protect Crypto Services service instance. For more information, see [Retrieving an instance ID](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-retrieve-instance-ID). 



A successful sync API request returns an HTTP 204 No Content response, which indicates that the IBM cloud service that is associated with the specified key is notified.
"checkpointed_source_seq": "403-g1AAAADfeJzLYWBgYMlgTmGQS0lKzi9KdUhJMjTRyyrNSS3QS87JL01JzCvRy0styQGqY0pkSLL___9_VmIymg5TXDqSHIBkUj1YUxyaJkNcmvJYgCRDA5AC6tuflZhGrPsgGg9ANAJtzMkCAPFSStc",
"changes_pending": 134,
"pid": "<0.1781.4101>",
"node": "dbcore@db11.julep.cloudant.net",
"docs_written": 0,
"missing_revisions_found": 0,
"replication_id": "d0cdbfee50a80fd43e83a9f62ea650ad+continuous",
"revisions_checked": 0,
"source": "https://repl:@tsm.cloudant.com/tsm-admin/",
"source_seq": "537-g1AAAADfeJzLYWBgYMlgTmGQS0lKzi9KdUhJMjTUyyrNSS3QS87JL01JzCvRy0styQGqY0pkSLL___9_VmI9mg4jXDqSHIBkUj1WTTityWMBkgwNQAqob39WYhextkE0HoBoBNo4MQsAFuVLVQ",
"started_on": 1363274083
},
{
"user": "acceptly",
"updated_on": 1363273779,
"type": "indexer",
"node": "dbcore@db11.julep.cloudant.net",
"pid": "<0.20723.4070>",
"changes_done": 189,
"NodeSelectorKey": "failure-domain.beta.kubernetes.io/region",
"NodeSelectorValue": "us-south"
}
defaultcheck.json: 
{
"MaxUnavailablePercentage": 20
}
<check_name>: 
{
"MaxUnavailablePercentage": <value_in_percentage>,
"NodeSelectorKey": "<node_selector_key>",
"NodeSelectorValue": "<node_selector_value>"
}
Show more

drain_timeout_seconds
: Optional: The timeout in seconds to wait for the [drain](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) to complete. Draining a worker node safely removes all existing pods from the worker node and reschedules the pods onto other worker nodes in the cluster. Accepted values are integers in the range 1 - 180. The default value is 30.

zonecheck.json and regioncheck.json
: Two checks that define a rule for a set of worker nodes that you can identify with the specified NodeSelectorKey and NodeSelectorValue. The zonecheck.json identifies worker nodes based on their zone label, and the regioncheck.json uses the region label that is added to every worker node during provisioning. In the example, 30% of all worker nodes that have dal13 as their zone label and 20% of all the worker nodes in us-south can be unavailable during the update.

defaultcheck.json
: If you don't create a config map or the map is configured incorrectly, the Kubernetes default is applied. By default, only 20% of the worker nodes in the cluster can be unavailable at a time. You can override the default value by adding the default check to your config map. In the example, every worker node that is not specified in the zone and region checks (dal13 or us-south) can be unavailable during the update.

MaxUnavailablePercentage
For more information, see MySQL's [Checking Replication Status](https://dev.mysql.com/doc/refman/5.7/en/replication-administration-status.html).





 Read Replica Users and Privileges 



* Any user on the source database instance, even ones present before read replica provision, can log in to and run reads on a read replica with the same privileges to objects that they have on the source database instance.
* If you have more than one read replica that is attached to a source database instance, a user that is created on the source is also created on all of the other read replicas.
* Users that are created on the source database instance persist on the read replica when it is promoted to a stand-alone deployment, including the admin user. When the read replica is promoted, the users and privileges for all users on the source database instance are transferred to the promoted deployment.
* Write operations on the read replica for all users are not filtered or rejected, but fail at the database level.
* Read replica users who are created on a read replica are able to connect to the source database instance with SELECT permission.









 Resyncing a Read Replica 

If you need to resync a read replica, click the Resync Read Replica button. Resyncing is a disruptive operation and performing a resync tears down and rebuilds the data in the read replica. The read replica is not able to perform any other operations or run any queries while a resync is running. Queries are not rerouted to the source database instance, so any connections to the read replica fail until it is finished resyncing.

The amount of time it takes to resync a read replica varies, but the process can be very long running.

To start a resync through the CLI, use the [cdb read-replica-resync](https://cloud.ibm.com/docs/databases-cli-plugin?topic=databases-cli-plugin-cdb-referenceread-replica-resync) command.

ibmcloud cdb read-replica-resync <deployment name>
Disk 4.5 GB VMDK resident on shared storage with 4 GB swap 



Because the NSX Edges are configured as active/passive in either the internal or dedicated deployment, vSphere® Distributed Resource Scheduler (DRS) anti-affinity rules must be created by the user to ensure that NSX Edges do not run on the same host as their respective peer appliance.



Table 3. vSphere Distributed Resource Scheduler rules

 Field Value 

 Name NSX Edge OpenShift 
 Type Separate VMs 
 Members openshift-edge-0 <br>openshift-edge-1 







 NSX Load Balancer specifications 

Within the Red Hat OpenShift environment, two load balancers for accessing the control plane nodes and the worker nodes are required. The NSX Edge is enabled to use load balancing and is configured with application profiles that use a certificate for inbound connection from the source. The NSX Edge is also configured with load-balancing pools to point to the Red Hat OpenShift Primaries and Red Hat OpenShift Workers. Additionally, a virtual server is created with a virtual IP address (vIP) on the private interface with rules that connect the pools with vIP.



Table 4. NSX load balancer specifications

 Description Port number Algorithm Monitor Members Protocol IP subnet 

 Application load balancer 80 ROUND-ROBIN default_tcp_monitor Worker nodes TCP IBM Cloud 10.x 
 Application load balancer 443 ROUND-ROBIN default_tcp_monitor Worker nodes TCP IBM Cloud 10.x 
 API and API-INT load balancer 6443 ROUND-ROBIN default_tcp_monitor Bootstrap and primary nodes TCP IBM Cloud 10.x 
 API and API-INT load balancer 22623 ROUND-ROBIN default_tcp_monitor Bootstrap and primary nodes TCP IBM Cloud 10.x 







 Red Hat OpenShift specifications 

The following tables show the specifications of the management node, control plane node, and worker node.

Management node

Control plane node

Worker node



Table 5. Management node specifications

 Host description vCPU Memory (GB) Disk (GB) OS 

 Management0 2 8 50 Red Hat Enterprise Linux® 8.0 







 Related links
RHEL 7 packages N/A N/A Updated worker node images with package updates for [CVE-2019-11729](https://nvd.nist.gov/vuln/detail/CVE-2019-11729) and [CVE-2019-11745](https://nvd.nist.gov/vuln/detail/CVE-2019-11745). 
 Red Hat OpenShift node 3.11.154 3.11.157 See the [Red Hat OpenShift release notes](https://docs.openshift.com/container-platform/3.11/release_notes/ocp_3_11_release_notes.htmlocp-3-11-157). 
 Maximum process IDs (PIDs) for pods N/A N/A Updated to support scaling the maximum allowed pod process IDs (PIDs) based on the [worker node machine type](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodesresource_limit_node). 







 Change log for master fix pack 3.11.154_1536_openshift, released 17 December 2019 

The following table shows the changes that are in the master fix pack 3.11.154_1536_openshift.



Changes since version 3.11.154_1534

 Component Previous Current Description 

 IBM Cloud Block Storage driver and plug-in N/A N/A Fixed a bug that might prevent updating the driver and plug-in components. 
 IBM Cloud File Storage for Classic plug-in and monitor 353 354 Updated to support [non-root user access to an NFS file share](https://cloud.ibm.com/docs/openshift?topic=openshift-debug_storage_file) by allocating a group ID (GID) in the storage class. 
 IBM Cloud Controller Manager v1.15.6-182 v1.15.6-200 Updated version 1.0 and 2.0 network load balancers (NLBs) to prefer scheduling NLB pods on worker nodes that don't currently run any NLB pods.
* [Member](https://cloud.ibm.com/docs/blockchain?topic=blockchain-glossaryglossary-member)
* [MSP](https://cloud.ibm.com/docs/blockchain?topic=blockchain-glossaryglossary-msp)
* [Network](https://cloud.ibm.com/docs/blockchain?topic=blockchain-glossaryglossary-network)
* [Node](https://cloud.ibm.com/docs/blockchain?topic=blockchain-glossaryglossary-node)
* [Ordering node](https://cloud.ibm.com/docs/blockchain?topic=blockchain-glossaryglossary-orderer)
* [Organization](https://cloud.ibm.com/docs/blockchain?topic=blockchain-glossaryglossary-organization)
* [Out of band](https://cloud.ibm.com/docs/blockchain?topic=blockchain-glossaryglossary-out-of-band)
* [Peer](https://cloud.ibm.com/docs/blockchain?topic=blockchain-glossaryglossary-peer)
* [Propose](https://cloud.ibm.com/docs/blockchain?topic=blockchain-glossaryglossary-propose)
* [Quorum](https://cloud.ibm.com/docs/blockchain?topic=blockchain-glossaryglossary-quorum)
* [Raft](https://cloud.ibm.com/docs/blockchain?topic=blockchain-glossaryglossary-raft)
* [SDK](https://cloud.ibm.com/docs/blockchain?topic=blockchain-glossaryglossary-sdk)
* [Service credentials](https://cloud.ibm.com/docs/blockchain?topic=blockchain-glossaryglossary-service-credentials)
: If you use the add-on, the [latest version build updates](https://cloud.ibm.com/docs/openshift?topic=openshift-hpcs-router-changelog) are automatically applied to your cluster.

IBM Cloud Image Key Synchronizer add-on
: If you use the add-on, the [latest version build updates](https://cloud.ibm.com/docs/openshift?topic=openshift-image-key-synchronizer-changelog) are automatically applied to your cluster.





 12 April 2021 

Worker node versions
: Worker node fix pack update change log documentation is available for version [4.6.23_1539_openshift](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_464623_1539), [4.5.35_1535_openshift](https://cloud.ibm.com/docs/openshift?topic=openshift-changelog_archive4535_1535), [4.4.33_1538_openshift](https://cloud.ibm.com/docs/openshift?topic=openshift-changelog_archive4433_1538), and [3.11.404_1585_openshift](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_311311404_1585).





 5 April 2021 

Deprecated data centers for classic clusters
: Houston (hou02) and Oslo (osl01) are deprecated and become unsupported later this year.
[Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/icons/checkmark-icon.svg) ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/icons/checkmark-icon.svg) ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/icons/checkmark-icon.svg) 
 Ordering nodes ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/icons/checkmark-icon.svg) ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/icons/checkmark-icon.svg) + anti-affinity ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/icons/checkmark-icon.svg) + anti-affinity ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/icons/checkmark-icon.svg) 
 CA replica sets !
Working with failover 

You can initiate failover from your primary IBM Cloud® Juniper vSRX to a backup device, so that all control and data plane traffic is routed through the secondary gateway device after failover.

This section is only applicable if your Juniper vSRX gateway devices are provisioned in High-Availability mode.

To do so, perform the following procedure:



1. Login to your primary vSRX gateway device.
2. Enter CLI mode by running the command cli at the console prompt. When you enter CLI mode, the console displays the node role, either primary or secondary.

Ensure that you are in the primary node. If you are not, exit and login to the other vSRX gateway device of the pair.
3. On the primary vSRX gateway device, run the command show chassis cluster status.

The output should be similar to the following:

Monitor Failure codes:
CS Cold Sync monitoring FL Fabric Connection monitoring
GR GRES monitoring HW Hardware monitoring
IF Interface monitoring IP IP monitoring
LB Loopback monitoring MB Mbuf monitoring
NH Nexthop monitoring NP NPC monitoring
SP SPU monitoring SM Schedule monitoring
CF Config Sync monitoring

Cluster ID: 2
Node Priority Status Preempt Manual 	Monitor-failures

Redundancy group: 0 , Failover count: 1
node0 100 primary no no None
node1 1 secondary no no None
Redundancy group: 1 , Failover count: 1
node0 100 primary yes no None
node1 1 secondary yes no None

{primary:node0}
Show more

Ensure that, for both redundancy groups, the same node is set as primary. It is possible for different nodes to be set as the primary role in different redundancy groups.

The vSRX, by default, sets Preempt to yes for Redundancy group 1, and no for Redundancy group 0.
file interactive-commands {
interactive-commands any;
}
}
ntp {
server 10.0.77.54;
}
}
chassis {
cluster {
control-link-recovery;
reth-count 4;
heartbeat-interval 2000;
heartbeat-threshold 8;
redundancy-group 0 {
node 0 priority 100;
node 1 priority 1;
}
redundancy-group 1 {
node 0 priority 100;
node 1 priority 1;
inactive: preempt;
interface-monitor {
ge-0/0/3 weight 130;
ge-0/0/4 weight 130;
ge-7/0/3 weight 130;
ge-7/0/4 weight 130;
}
}
}
}
security {
log {
mode stream;
report;
}
address-book {
global {
address SL8 10.1.192.0/20;
address SL9 10.1.160.0/20;
address SL4 10.2.128.0/20;
address SL5 10.1.176.0/20;
address SL6 10.1.64.0/19;
address SL7 10.1.96.0/19;
address SL1 10.0.64.0/19;
address SL2 10.1.128.0/19;
address SL3 10.0.86.0/24;
address SL20 10.3.80.0/20;
address SL18 10.2.176.0/20;
address SL19 10.3.64.0/20;
address SL16 10.2.144.0/20;
address SL17 10.2.48.0/20;
address SL14 10.1.208.0/20;
address SL15 10.2.80.0/20;
address SL12 10.2.112.0/20;
address SL13 10.2.160.0/20;
Note: The management IP address is the 10.x.x.x IP address of the server if you used the default installation.

When you work with bonded networks, a newly joined worker can have its interfaces that are attached to the incorrect bonded networks. To correct this issue, destroy the bonds on the worker from the command line and re-create the bonds with the proper PIFs and networks.

You have two methods of ejecting a worker node from the pool. The first is by using XenCenter. Go to Pool and select Remove Server. Follow the simple step-by-step on-screen instructions that are provided. The other method is by using the command line. The removal of a node can be done from any node in the pool. You need to locate the uuid of the node you want to eject by running the following command:

xe host-list

Then, run this command:

xe pool-eject uuid=

Note: When a node ejects, it reboots into a clean installation, which includes the removal of the networking configuration that is used to provide public and private connectivity. The password of the worker node is still the same as the controller node after ejection from the pool. You might have to reconfigure networking via IPMI as the removal can break the workers' settings.
XFS file systems are created on those logical volumes and are mounted on /nfsshare, /nfshare/export/sap${SID}, /nfsshare/export/saptrans.





 Prerequisites 



* A [Red Hat Customer Portal](https://access.redhat.com/) account.
* An [IBM Cloud account](https://cloud.ibm.com/docs/account?topic=account-account-getting-started).



A virtual hostname and IP address is required for the NFS server. Make sure that the virtual IP address is defined on the network interface, and reachable in the network.

Name resolution and reverse lookup for physical and virtual IP names and addresses must be unique and consistent on all NFS server and client nodes. Details of the NFS clients (subnet, required NFS export options) must be available. You need to enter them during the cluster setup.





 Preparing for a highly available NFS server 

Use the following information to prepare the environment for a highly available NFS server.



 Installing NFS software packages 

On both nodes, run the following commands.

dnf install -y nfs-utils





 Preparing LVM objects 

All cluster nodes need access to the shared storage volumes, but only one node has exclusive read and write access to a volume.



 Preparing active-passive HA LVM 

On both nodes, edit file /etc/lvm/lvm.conf to include the system ID in the volume group.

vi /etc/lvm/lvm.conf

Search for parameter system_id_source and change its value to "uname".

Sample setting of the system_id_source parameter in /etc/lvm/lvm.conf:

system_id_source = "uname"

Verify that the LVM system ID for the node matches the uname -n output.

lvm systemid

uname -n

Sample output:

 lvm systemid
system ID: cl-nfs-1
 uname -n
cl-nfs-1





 Identifying the World Wide Names of shared storage volumes
Operator Lifecycle Manager 0.14.1-IKS-1 0.14.1-IKS-2 Updated image for [CVE-2020-1971](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1971) and [CVE-2020-28928](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28928). 







 Change log for worker node fix pack 1.17.15_1549, released 21 December 2020 

The following table shows the changes that are in the worker node fix pack 1.17.15_1549. Worker node patch updates can be applied by updating, reloading (in classic infrastructure), or replacing (in VPC infrastructure) the worker node.



Changes since version 1.17.15_1548

 Component Previous Current Description 

 Ubuntu 16.04 packages N/A N/A Updated worker node image with package updates for: [CVE-2020-1971](https://nvd.nist.gov/vuln/detail/CVE-2020-1971), [CVE-2020-27350](https://nvd.nist.gov/vuln/detail/CVE-2020-27350), [CVE-2020-27351](https://nvd.nist.gov/vuln/detail/CVE-2020-27351), [CVE-2020-8284](https://nvd.nist.gov/vuln/detail/CVE-2020-8284), [CVE-2020-8285](https://nvd.nist.gov/vuln/detail/CVE-2020-8285), and [CVE-2020-8286](https://nvd.nist.gov/vuln/detail/CVE-2020-8286).
Operator Lifecycle Manager 0.14.1-IKS-1 0.14.1-IKS-2 Updated image for [CVE-2020-1971](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1971) and [CVE-2020-28928](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28928). 







 Change log for worker node fix pack 1.18.13_1536, released 21 December 2020 

The following table shows the changes that are in the worker node fix pack 1.18.13_1536. Worker node patch updates can be applied by updating, reloading (in classic infrastructure), or replacing (in VPC infrastructure) the worker node.



Changes since version 1.18.13_1535

 Component Previous Current Description 

 Ubuntu 16.04 packages N/A N/A Updated worker node image with package updates for: [CVE-2020-1971](https://nvd.nist.gov/vuln/detail/CVE-2020-1971), [CVE-2020-27350](https://nvd.nist.gov/vuln/detail/CVE-2020-27350), [CVE-2020-27351](https://nvd.nist.gov/vuln/detail/CVE-2020-27351), [CVE-2020-8284](https://nvd.nist.gov/vuln/detail/CVE-2020-8284), [CVE-2020-8285](https://nvd.nist.gov/vuln/detail/CVE-2020-8285), and [CVE-2020-8286](https://nvd.nist.gov/vuln/detail/CVE-2020-8286).
Operator Lifecycle Manager 0.14.1-IKS-1 0.14.1-IKS-2 Updated image for [CVE-2020-1971](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1971) and [CVE-2020-28928](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28928). 







 Change log for worker node fix pack 1.16.15_1555, released 21 December 2020 

The following table shows the changes that are in the worker node fix pack 1.16.15_1555. Worker node patch updates can be applied by updating, reloading (in classic infrastructure), or replacing (in VPC infrastructure) the worker node.



Changes since version 1.16.15_1554

 Component Previous Current Description 

 Ubuntu 16.04 packages N/A N/A Updated worker node image with package updates for: [CVE-2020-1971](https://nvd.nist.gov/vuln/detail/CVE-2020-1971), [CVE-2020-27350](https://nvd.nist.gov/vuln/detail/CVE-2020-27350), [CVE-2020-27351](https://nvd.nist.gov/vuln/detail/CVE-2020-27351), [CVE-2020-8284](https://nvd.nist.gov/vuln/detail/CVE-2020-8284), [CVE-2020-8285](https://nvd.nist.gov/vuln/detail/CVE-2020-8285), and [CVE-2020-8286](https://nvd.nist.gov/vuln/detail/CVE-2020-8286).