vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Red Hat OpenShift on IBM Cloud toolkit 4.11.0+20220824 4.11.0+20220829 See the [Red Hat OpenShift on IBM Cloud toolkit release notes](https://github.com/openshift/ibm-roks-toolkit/releases/tag/v4.11.0+20220829). 







 Change log for master fix pack 4.11.0_1519_openshift and worker node fix pack 4.11.1_1520_openshift, released 31 August 2022 

The following table shows the changes that are in the master fix pack 4.11.0_1519_openshift and worker node fix pack 4.11.1_1520_openshift. Master patch updates are applied automatically. Worker node patch updates can be applied by updating, reloading (in classic infrastructure), or replacing (in VPC infrastructure) the worker node.



Changes since version 4.10.22_1528_openshift

 Component Previous Current Description 

 Calico v3.22.2 v3.23.3 See the [Calico release notes](https://docs.tigera.io/archive). 
 Calico Operator v1.25.7 v1.27.12 See the [Calico Operator release notes](https://github.com/tigera/operator/releases/tag/v1.27.12). 
 Cluster health image v1.3.9 v1.3.10 Updated Go dependencies and to Go version 1.18.5. 
 etcd v3.4.18 v3.5.4 See the [etcd release notes](https://github.com/etcd-io/etcd/releases/v3.5.4). 
 IBM Calico extension 997 1006 Updated to Go version 1.17.13. 
 IBM Cloud Block Storage driver and plug-in v2.2.8 v2.2.9 Updated to Go version 1.18.5. 
 IBM Cloud Controller Manager v1.23.8-7 v1.24.4-1 Updated Go dependencies and to Go version 1.18.5.
Red Hat OpenShift 4.4.16 4.4.17 See the [Red Hat OpenShift release notes](https://docs.openshift.com/container-platform/4.4/release_notes/ocp-4-4-release-notes.htmlocp-4-4-17). 







 Change log for master fix pack 4.4.16_1513_openshift, released 18 August 2020 

The following table shows the changes that are in the master fix pack patch update 4.4.16_1513_openshift. Master patch updates are applied automatically.



Changes since version 4.4.11_1511_openshift

 Component Previous Current Description 

 Cluster health image v1.1.8 v1.1.9 Updated to use Go version 1.13.13. 
 Cluster master operations N/A N/A Cluster master update operations are now canceled if a broken [Kubernetes admission webhook](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) is detected. 
 etcd v3.4.9 v3.4.10 See the [etcd release notes](https://github.com/etcd-io/etcd/releases/v3.4.10). 
 IBM Cloud Block Storage driver and plug-in 1.17 1.17.1 Updated to use Go version 1.13.8. 
 IBM Cloud File Storage for Classic plug-in and monitor 375 377 Fixed a bug that prevents persistent volume claim (PVC) creation failures from being retried. Updated to use Go version 1.13.8. 
 IBM Cloud RBAC Operator 8882606 d80b738 Updated image for [CVE-2020-12049](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12049) and to use Go version 1.13.14.
You can [enable operators](https://cloud.ibm.com/docs/openshift?topic=openshift-operators) from the OperatorHub in Red Hat OpenShift web console.

openshift-monitoring
: OpenShift Container Platform includes a [built-in monitoring stack](http://docs.openshift.com/container-platform/4.11/monitoring/monitoring-overview.html) for your cluster, that includes metrics and alert managing capabilities. For a comparison of the built-in monitoring stack and other options such as IBM Cloud Monitoring, see [Understanding options for logging and monitoring](https://cloud.ibm.com/docs/openshift?topic=openshift-health).

openshift-multus
: OpenShift Container Platform uses the Multus container network interface (CNI) plug-in to allow [multiple pod networks](https://docs.openshift.com/container-platform/4.11/networking/multiple_networks/understanding-multiple-networks.html). However, you can't configure the cluster to use multiple pod networks. Red Hat OpenShift on IBM Cloud clusters support only Calico, which is set up for your cluster by default. If enabled, [Service Mesh](https://docs.openshift.com/container-platform/4.11/service_mesh/v1x/servicemesh-release-notes.html) uses the Multus plug-in.

openshift-network-operator
: The [cluster network operator (CNO)](https://docs.openshift.com/container-platform/4.11/networking/cluster-network-operator.html) manages the cluster network components that are set up by default, such as the CNI pod network provider plug-in and DNS operator.

openshift-operator-lifecycle-manager
Red Hat OpenShift 4.9.19 4.9.22 For more information, see the [change logs](https://docs.openshift.com/container-platform/4.9/release_notes/ocp-4-9-release-notes.htmlocp-4-9-22) 
 HA proxy f6a2b3 15198fb Contains fixes for [CVE-2022-24407](https://nvd.nist.gov/vuln/detail/CVE-2022-24407). 







 Change log for worker node fix pack 4.9.19_1526_openshift, released 14 February 2022 



Changes since version 4.9.17_1523_openshift

 Component Previous Current Description 

 RHEL 7 Packages N/A N/A N/A 
 Red Hat OpenShift N/A 4.9.19 For more information, see the [change log](https://docs.openshift.com/container-platform/4.9/release_notes/ocp-4-9-release-notes.htmlocp-4-9-19). 
 HA proxy d38fa1 f6a2b3 [CVE-2021-3521](https://nvd.nist.gov/vuln/detail/CVE-2021-3521), [CVE-2021-4122](https://nvd.nist.gov/vuln/detail/CVE-2021-4122). 







 Change log for master fix pack 4.9.17_1525_openshift and worker node fix pack 4.9.17_1523_openshift, released 9 February 2022 

The following table shows the changes that are in the master fix pack 4.9.17_1525_openshift and worker node fix pack 4.9.17_1523_openshift. Master patch updates are applied automatically. Worker node patch updates can be applied by updating, reloading (in classic infrastructure), or replacing (in VPC infrastructure) the worker node.
: Red Hat OpenShift [4.4.16_1513_openshift](https://cloud.ibm.com/docs/openshift?topic=openshift-changelog_archive4416_1513), [4.3.31_1534_openshift](https://cloud.ibm.com/docs/openshift?topic=openshift-changelog_archive4331_1534), and [3.11.248_1564_openshift](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_311311248_1564)..





 6 August 2020 

CLI change log
: Updated the Red Hat OpenShift on IBM Cloud CLI plug-in change log page for the [release of version 1.0.143](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_cli_changelog10).





 5 August 2020 

Ingress ALB change log
: Updated the [nginx-ingress image build to 647 and the ingress-auth image build to 421](https://cloud.ibm.com/docs/containers?topic=containers-cluster-add-ons-changelogkube_ingress_changelog).





 3 August 2020 

Gateway appliance firewalls
: Updated the [required IP addresses and ports](https://cloud.ibm.com/docs/openshift?topic=openshift-firewallfirewall_private) that you must open in a private gateway device firewall.

Versions
: Worker node fix pack update change log documentation is available.
Find the name of the service network that is assigned for the service network interface from the IP Addresses table in the Edge Gateway Settings section. The format for the service network name is w<idx>-service<idx>, for example, w02-service02.
4. Click the Applied On arrow and select the service network interface.
5. Add the Service network IP to the Original Source IP/Range.
6. Click Protocol and select the port type for inbound traffic.
7. For the TCP or UDP protocols, click Original Port and enter the port range that you want to allow. Skip this step for the Any protocol.
8. The Translated Source IP/Range is the IP addresses of the VM connected to the routed Organization virtual data center.
9. For the TCP or UDP protocols, select the Translated Port to route the traffic to. Skip this step for the Any protocol.
10. Skip the ICMP Type and optionally enter a description. Click KEEP.
11. Click Save changes.







 Validating the private network endpoint connection 

To validate the private network endpoint connection, log in to the virtual server instance resource in your IBM Cloud infrastructure account. To connect to a VM in the virtual data center, use SSH, RDP, or Ping (if ICMP is enabled).

Ensure that the Organization virtual data center network type is routed.

For more information about creating a private network endpoint, see [Order a private network endpoint to connect your IBM account to your VMware Shared virtual data center](https://mlwiles.github.io/vmwaresolutions/vcd/order-pne/). An example of a successful configuration is also provided.







 Using Network High Availability 

Use Network High Availability to anchor your VMware Cloud Director network in two data centers.

You must access data center groups to use the Network High Availability feature. A data center group acts as a cross-virtual data center router that provides the following.



* Centralized networking administration
* Configuration for multiple egress points in multiple virtual data centers
* East-west traffic between all networks within the group
: All services that are deployed to the cluster are assigned a private IP address in the 172.21.0.0/16 range by default.

Size requirements
: When you specify a custom subnet, the subnet must be specified in CIDR format with a size of at least /24, which allows a maximum of 255 services in the cluster, or larger.

Range requirements
: The pod and service subnets can't overlap each other. The subnet that you choose must be within one of the following ranges: - 172.17.0.0 - 172.17.255.255 - 172.21.0.0 - 172.31.255.255 - 192.168.0.0 - 192.168.254.255 - 198.18.0.0 - 198.19.255.255
: The 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16, and 172.20.0.0/16 ranges are prohibited.







 Network segmentation 

Network segmentation describes the approach to divide a network into multiple sub-networks. Apps that run in one sub-network can't see or access apps in another sub-network. For more information about network segmentation options and how they relate to VLANs, see [this cluster security topic](https://cloud.ibm.com/docs/openshift?topic=openshift-securitynetwork_segmentation).

However, in several situations, components in your cluster must be permitted to communicate across multiple private VLANs. For example, if you want to create a multizone cluster, if you have multiple VLANs for a cluster, or if you have multiple subnets on the same VLAN, the worker nodes on different subnets in the same VLAN or in different VLANs can't automatically communicate with each other. You must enable either a Virtual Router Function (VRF) or VLAN spanning for your IBM Cloud infrastructure account.

Virtual Routing and Forwarding (VRF)
: VRF enables all the VLANs and subnets in your infrastructure account to communicate with each other. Additionally, a VRF is required to allow your workers and master to communicate over the private cloud service endpoint.
Select the service network available to your virtual data center. Click the right arrow to move the service network into the right side filter column.
* For Action, select Accept.
* To define a destination IP address or range, click the IP in the destination cell and set the IP address or range to allow everything on that subnet. For example, 192.168.100.2 or 192.168.100.0/24.







 Source NAT definitions to the IBM Service Network (Private) 

A source NAT rule is necessary to allow traffic from the Organization virtual data center network into the IBM Cloud Service Network. This rule is used to enable VM access to IBM Cloud Services such as update servers, DNS servers, NTP servers, or to get to the IBM Cloud Object Storage.

From the virtual data center for that edge gateway, create the source NAT definitions to the IBM Service Network (Private). For more information, see [Add a SNAT or a DNAT rule](https://docs.vmware.com/en/VMware-Cloud-Director/10.1/VMware-Cloud-Director-Tenant-Portal-Guide/GUID-1DE460AE-DCCC-4BC8-96AC-52D06A4AFDE3.html).

Under the NAT44 Rules, click SNAT Rule and create the configuration by using the following selection.



* For Applied On, select the service network.
* For Original Source IP/Range, enter your Organization virtual data center Gateway CIDR.
* For Translated Source IP/Range, click SELECT. In the Select IP Address Network menu, select the service network and choose one of the service network addresses that were assigned to your virtual data center.
* Optionally, enter the destination IP addresses.
* Optionally, enter the destination port.
* Optionally, enter the description. A description can be useful to identify the SNAT rule later.
* Set to Enabled.
* Optionally, enable logging. Logs are not preserved. If you want to have historical data, you must set up a syslog server.
From the tenant portal, click Data Centers.
2. From the main page under Virtual Data Center, click the virtual data center where you would like to configure the private network.
3. In the left pane under Networking, click Edges.
4. In the right pane, select the network and click SERVICES.
5. Click the Firewall tab and click + to add a firewall rule.
6. Add the private network IP that you collected from the IBM Cloud virtual data center details page to the Source field.
7. Add the service network IP that you collected from the IBM Cloud virtual data center details page to the Destination field.
8. Select the Protocol (TCP, UDP, or Any) and specify ports for the Service field.
9. Select Accept for the Action field.
10. Click Save changes.



For more information, see [Add an NSX data center for vSphere Edge Gateway firewall rule](https://docs.vmware.com/en/VMware-Cloud-Director/10.1/VMware-Cloud-Director-Tenant-Portal-Guide/GUID-97ADAF42-598B-44B2-80EF-8B215B743C78.html).





 Configuring DNAT rules for the NSX Edge Services Gateway 

A Destination NAT rule is necessary to allow traffic from a private network endpoint to the virtual data center.



1. From the Edge Gateway Services pane, click the NAT tab.
2. Under the NAT44 Rules, click + DNAT Rule.
3. Find the name of the service network that is assigned for the service network interface from the IP Addresses table in the Edge Gateway Settings section. The format for the service network name is w<idx>-service<idx>, for example, w02-service02.
4. Click the Applied On arrow and select the service network interface.
5. Add the Service network IP to the Original Source IP/Range.
6. Click Protocol and select the port type for inbound traffic.
7.
Managing Power Systems Virtual Servers (IAM) 

Identity and access management (IAM) enables you to securely authenticate users, control access to Power® Systems Virtual Server resources with resource groups, and allow access to specific resources for a set of users with access groups. IAM is your one-stop shop for all user and resource management in the IBM Cloud.

You can assign IAM authorizations based on the following criteria:



* Individual users
* Access groups
* Specific types of resources
* Resource groups



For more information about IAM, review the following information:



* [Getting started with IAM](https://cloud.ibm.com/docs/account?topic=account-access-getstarted)
* [Managing resource groups](https://cloud.ibm.com/docs/account?topic=account-rgs)
* [Setting up access groups](https://cloud.ibm.com/docs/account?topic=account-groups)
* [IAM concepts](https://cloud.ibm.com/docs/account?topic=account-iamoverview)





 Platform access roles 

You can use platform access roles to enable users to complete tasks on IBM Cloud resources, such as creating users or adding services.

The following table displays the IAM platform access roles and the corresponding type of control that is allowed by Power Systems Virtual Server:



Table 1. IAM platform access roles

 Platform access role Type of access allowed 

 Viewer View instances and list instances. 
 Operator View instances and list instances. 
 Editor View instances, list instances, create instances, and delete instances. 
 Administrator View instances, list instances, create instances, delete instances, and assign policies to other users. 







 Service access roles 

You can use the service access roles to define what users can do with Power Systems Virtual Server functions. The following table displays the IAM service access roles and the corresponding actions a user can complete with Power Systems Virtual Server:



Table 2. IAM service access roles

 Service access role Description of actions 

 Reader View all resources (such as SSH keys, storage volumes, and network settings). You cannot make any changes to the resources.
The HCX-IX service appliance provides replication and vMotion-based migration capabilities over the Internet and private lines to the destination site whereas providing strong encryption, traffic engineering, and VM mobility.





 HCX WAN Optimization Appliance (HCX-WO) 

The VMware HCX WAN Optimization service improves performance characteristics of the private lines or Internet paths by applying WAN optimization techniques like the data de-duplication and line conditioning. It makes performance closer to a LAN environment. It accelerates onboarding to the destination site by using Internet and VPN. This way, immediate migration is allowed, without the need to wait for Direct Link and related MPLS circuits, which can naturally be used in migration, too.





 HCX Network Extension Virtual Appliance (HCX-NE) 

The HCX Network Extension service provides a low-touch operation for high performance (4 - 6 Gbps) Layer 2 Extension from environments that use a vSphere Distributed Switch, or NSX Networking. With HCX Network Extension, you can keep the same IP and MAC addresses during VM migrations. HCX Network Extension with Mobility Optimized Networking eliminates tromboning between migrated VMs on different extended segments, and VMs on native NSX-T™ networks at the destination







 Deployment architecture 

The deployment architecture consists of the HCX components within the IBM Cloud and with client on-premises. In this design, the architecture specifies a hub-and-spoke model that exists between the source environment and the IBM Cloud. The source estate serves as the hub with connections to different IBM Cloud environments as shown in the following figure. In this model, site peering is established over the Internet.

Zoom

![HCX with single source over Public Network](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/hcx-public.svg)

Figure 1. HCX with single source over Public Network

Alternatively, the architecture also allows site peering over Private Internet.

Zoom

!
Pilot uses three types of configuration resources to manage traffic within its service mesh: [Virtual Services](https://istio.io/latest/docs/reference/config/networking/virtual-service/), [Destination Rules](https://istio.io/latest/docs/reference/config/networking/destination-rule/), and [Service Entries](https://istio.io/latest/docs/reference/config/networking/service-entry/).



 A/B testing with Istio 

A/B testing is a method of performing identical tests against two separate service versions in order to determine which performs better. To prevent Istio from performing the default routing behavior between the original and modernized service, define the following rules:



1. Run the following command to create default destination rules for the Bookinfo services,

oc create -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.2/samples/bookinfo/networking/destination-rule-all.yaml

A [DestinationRule](https://istio.io/latest/docs/reference/config/networking/virtual-service/Destination) defines policies that apply to traffic intended for a service after routing has occurred. These rules specify configuration for load balancing, connection pool size from the sidecar, and outlier detection settings to detect and evict unhealthy hosts from the load balancing pool. Any destination host and subset referenced in a VirtualService rule must be defined in a corresponding DestinationRule.
2. A VirtualService defines a set of traffic routing rules to apply when a host is addressed. Each routing rule defines matching criteria for traffic of a specific protocol. If the traffic is matched, then it is sent to a named destination service (or subset/version of it) defined in the registry. Run the below command to send all reviews traffic to v1:

oc create -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.2/samples/bookinfo/networking/virtual-service-all-v1.yaml
Getting started with VLANs 

Virtual Local Area Networks (VLANs) are used by IBM Cloud® to isolate broadcast traffic on the public and private networks.

VLANs are assigned as needed to fulfill other offerings. For instance, if you place a compute order for a data center in which you don't yet have a presence, you automatically receive a VLAN. Additional compute orders for the same data center, which do not specify network requirements, usually are placed in the previously assigned VLAN. All VLANs that are assigned automatically are also removed automatically when you no longer have resources that require them.

VLANs are specific to the routers used in IBM Cloud data centers, and a data center contains multiple routers for both the public and private networks. Thus, it is possible that multiple VLANs can be assigned within a single data center. It also is possible to order additional VLANs to construct more complex network topologies; typically in conjunction with a [Virtual Router Appliance](https://cloud.ibm.com/docs/virtual-router-appliance?topic=virtual-router-appliance-getting-started).

We refer to purchased VLANs as Premium VLANs and VLANs automatically managed by IBM Cloud as Automatic VLANs. Learn more about how VLANs operate in [About VLANs](https://cloud.ibm.com/docs/vlans?topic=vlans-about-vlans).



 Managing VLANs 

Follow these steps to review the VLANs on your account.



1. From your browser, open the [IBM Cloud console](https://cloud.ibm.com/) and log in to your account.
2. From the console, click the Menu icon ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/icons/icon_hamburger.svg) and select Classic Infrastructure.
3. Select Network > IP Management > VLANs.



The VLANs listing displays information about your VLANs, and it provides access to each VLAN, along with associated devices or subnets.



 Understanding pod versus data center selection
VMware HCX source-side architecture 

Review the source architecture for the VMware® HCX™ components that are typically deployed in the customer data center. The tasks that can be accomplished and the features that support and enhance migration and network extension are also presented.



* HCX owns the source and destination encryption and decryption processes, ensuring consistent security and providing admission for hybrid workflows such as virtual machine (VM) migration and network extension.
* HCX creates an optimized, software-defined WAN to increase stretched network performance, enabling performance that approaches LAN speed.
* HCX also enables bidirectional workload migration to IBM Cloud® Networking services.
* HCX integrates with vSphere vCenter and is managed from the vSphere Web Client.





 Understanding HCX 

HCX supports a many-to-many relationship between on-premises vCenters and IBM Cloud. vCenter Server in Linked Mode is supported.

During the installation, the HCX Manager virtual appliance is imported and configured as a plug-in for the on-premises vCenter. This plug-in is then used to configure the software-defined WAN service deployment. The automated configuration provisions each hybrid service appliance as a VM in the on-premises vCenter, and deploys a corresponding VM in IBM Cloud.

A successful deployment requires the following items:



* Sufficient resources for the virtual appliances.
* The network must allow the appliances to communicate with both local and remote virtual appliances, and other VMs.







 Deployment overview 

The HCX Manager VM is installed first, and it manages the installation of any other service VM appliances on premises and in the cloud.

The following steps are basic installation tasks:



1. Obtain HCX Connector virtual appliance OVA file.
2. From the vSphere Web Client, install the HCX Manager service virtual appliance in the on-premises vCenter that connects to IBM Cloud.
3. From the vSphere Web Client, register an IBM Cloud endpoint with the HCX plug-in. Registration establishes the one-to-one relationship between the on-premises HCX and the HCX instance on IBM Cloud.
4.