vania-janet/multiturn-rag-retrieval-data huggingface dataset:
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o ens3 -j MASQUERADE
ListenPort = 51820

[Peer]
PublicKey = <wireguard_client_public_key>
AllowedIPs = 192.168.3.217/32
3. Stop the WireGuard server and start it again to apply your changes.

wg-quick down wg0

wg-quick up wg0
4. Show the updated status of your WireGuard server connections. The interface and peer connections are displayed in your CLI output.

wg show wg0

Example output

interface: wg0
public key: AA11aa1aa/aa1AaA1AaaaAAAaa1AAaaA1aAAAAaaAAA=
private key: (hidden)
listening port: 51820

peer: a11aAaA+AaaaaaaaA1aAAaAA1/1AaAaAaaAA1AAA/aA=
allowed ips: 192.168.3.217/32



12. Check that you can connect to the private Red Hat OpenShift cluster from your local machine.



1. From the [Red Hat OpenShift clusters console](https://cloud.ibm.com/kubernetes/clusters?platformType=openshift), select your private cluster that you want to connect to.
2. On the cluster overview page, go to the Networking section and copy the Ingress subdomain.
3. Ping the Ingress subdomain to verify that you can connect to your private Red Hat OpenShift cluster.
4. From the cluster overview page, open the Red Hat OpenShift web console.
For more information, see [Allowing Red Hat OpenShift on IBM Cloud to access other IBM Cloud resources by using CBR](https://cloud.ibm.com/docs/openshift?topic=openshift-cbrcbr-integrations).

Review the [limitations](https://cloud.ibm.com/docs/openshift?topic=openshift-cbrcbr-limitations) before you create network zones.



 Creating network zones from the API 

You can create network zones by using the /v1/zones API. For more information, see the [API docs](https://cloud.ibm.com/apidocs/context-based-restrictionscreate-zone). You can add the containers-kubernetes service to your network zones to allow Red Hat OpenShift on IBM Cloud to access resources and services in your account.

You can include multiple address types in your network zone payload. For more information, see the example payload in the [API docs](https://cloud.ibm.com/apidocs/context-based-restrictionscreate-zone).

Example payload to add Red Hat OpenShift on IBM Cloud to a network zone. The serviceRef attribute for Red Hat OpenShift on IBM Cloud is containers-kubernetes.

{
"name": "Example zone 1",
"description": "",
"addresses": [
{
"type": "serviceRef",
"ref": {
"service_name": "containers-kubernetes",
"account_id": "ACCOUNT-ID"
}
}
]
}

Example payload to add multiple services, IP addresses, and VPCs to a network zone.

{
"name": "zone",
"description": "",
"addresses": [
{
"type": "ipAddress",
"value": "192.168.0.0"
},
{
"type": "vpc",
: The Konnectivity server works with the Konnectivity agent to securely connect the master to the worker node. This connection supports apiserver proxy calls to your pods and services; oc exec, attach, and logs calls to the kubelet; and mutating and validating webhooks.

Admission controllers
: Admission controllers are implemented for specific features in Red Hat OpenShift on IBM Cloud clusters. With admission controllers, you can set up policies in your cluster that determine whether a particular action in the cluster is allowed or not. In the policy, you can specify conditions when a user can't perform an action, even if this action is part of the general permissions that you assigned the user by using RBAC. Therefore, admission controllers can provide an extra layer of security for your cluster before an API request is processed by the Red Hat OpenShift API server. When you create a Red Hat OpenShift cluster, the following [Kubernetes admission controllers](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) are automatically installed in the given order in the Red Hat OpenShift master, which can't be changed by the user:



* NamespaceLifecycle
* LimitRanger
* ServiceAccount
* DefaultStorageClass
* ResourceQuota
* StorageObjectInUseProtection
* PersistentVolumeClaimResize
* Priority
* BuildByStrategy
* OriginPodNodeEnvironment
* PodNodeSelector
* ExternalIPRanger
* NodeRestriction
* SecurityContextConstraint
* SCCExecRestrictions
* PersistentVolumeLabel
* OwnerReferencesPermissionEnforcement
* PodTolerationRestriction
* openshift.io/JenkinsBootstrapper
* openshift.io/BuildConfigSecretInjector
* openshift.io/ImageLimitRange
* openshift.io/RestrictedEndpointsAdmission
* openshift.io/ImagePolicy
* openshift.io/IngressAdmission
Configuring classic subnets and IP addresses 

Change the pool of available portable public or private IP addresses by adding subnets to your Red Hat® OpenShift® on IBM Cloud® cluster.

The content on this page is specific to classic clusters. For information about VPC clusters, see [Configuring subnets and IP addresses for VPC clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-subnets).



 Overview of classic networking in Red Hat OpenShift on IBM Cloud 

Understand the basic concepts of classic networking in Red Hat OpenShift on IBM Cloud clusters. Red Hat OpenShift on IBM Cloud uses VLANs, subnets, and IP addresses to give cluster components network connectivity.



 VLANs 

When you create a cluster, the cluster's worker nodes are connected automatically to a VLAN. A VLAN configures a group of worker nodes and pods as if they were attached to the same physical wire and provides a channel for connectivity among the workers and pods.

VLANs for standard clusters
: In standard clusters, the first time that you create a cluster in a zone, a public VLAN and a private VLAN in that zone are automatically provisioned for you in your IBM Cloud infrastructure account. For every subsequent cluster that you create in that zone, you must specify the VLAN pair that you want to use in that zone. You can reuse the same public and private VLANs that were created for you because multiple clusters can share VLANs. You can either connect your worker nodes to both a public VLAN and the private VLAN, or to the private VLAN only. If you want to connect your worker nodes to a private VLAN only, you can use the ID of an existing private VLAN or [create a private VLAN](https://cloud.ibm.com/docs/cli/reference/ibmcloud?topic=cli-manage-classic-vlanssl_vlan_create) and use the ID during cluster creation.

To see the VLANs that are provisioned in each zone for your account, run ibmcloud oc vlan ls --zone <zone>.
Change log: Red Hat OpenShift Kubernetes OCP4 profile 

In this change log, you can learn about the latest changes, improvements, and updates for the Red Hat OpenShift Kubernetes OCP4 profile. The change log lists changes that were made, ordered by the version number.



  Profile versioning 

When specifications or controls are edited, removed from, or added to a profile in a way that is not compatible with the current version, a new version is released. To take advantage of the changes in a new version, update your attachments to use the newest profile version.

This profile is consistently updated and is not an exhaustive list of all the controls that might be required for every organization. Be sure to validate the available controls to determine where you might need to supplement your workloads with other security measures.



  Active versions 

The following table shows the service behavior changes for each version date. Switching to a later version date activates all changes that are introduced in earlier versions.



Table. Active versions of the Red Hat OpenShift Kubernetes OCP4 profile

 Version number   Release date 

 Version 1.0.0    2023-06-07   









  Version 1.0.0 

Now available
:   Released today, 6 June 2023, the Red Hat OpenShift Kubernetes OCP4 profile is a collection of controls designed to validate the configuration of your IBM Cloud Red Hat OpenShift clusters.
: API audit logging to monitor user-initiated activities is currently not supported.





 Forwarding cluster and app logs to IBM Log Analysis 

Use the Red Hat OpenShift on IBM Cloud observability plug-in to create a logging configuration for IBM Log Analysis in your cluster, and use this logging configuration to automatically collect and forward pod logs to IBM Log Analysis.

Considerations for using the Red Hat OpenShift on IBM Cloud observability plug-in:



* You can have only one logging configuration for IBM Log Analysis in your cluster at a time. If you want to use a different IBM Log Analysis service instance to send logs to, use the [ibmcloud ob logging config replace](https://cloud.ibm.com/docs/containers?topic=containers-observability_clilogging_config_replace) command.
* Red Hat OpenShift clusters in Satellite can't currently use the Red Hat OpenShift on IBM Cloud console or the observability plug-in CLI to enable logging for Satellite clusters. You must manually deploy logging agents to your cluster to forward logs to Log Analysis.
* If you created a Log Analysis configuration in your cluster without using the Red Hat OpenShift on IBM Cloud observability plug-in, you can use the [ibmcloud ob logging agent discover](https://cloud.ibm.com/docs/containers?topic=containers-observability_clilogging_agent_discover) command to make the configuration visible to the plug-in. Then, you can use the observability plug-in commands and functionality in the IBM Cloud console to manage the configuration.



Before you begin



* Verify that you are assigned the Editor platform access role and Manager server access role for IBM Log Analysis.
* Verify that you are assigned the Administrator platform access role and the Manager service access role for all Kubernetes namespaces in IBM Cloud Kubernetes Service to create the logging configuration. To view a logging configuration or launch the Log Analysis dashboard after the logging configuration is created, users must be assigned the Administrator platform access role and the Manager service access for the ibm-observe Kubernetes namespace in IBM Cloud Kubernetes Service.
* If you want to use the CLI to set up the logging configuration:
A Red Hat CoreOS enabled location unlocks more features such as minimal outbound network requirements, bring your own key (BYOK) or keep your own key (KYOK) support for encrypting cluster secrets, HTTP proxy for outbound traffic, OpenShift virtualization, and single node cluster topology. But it has a higher infrastructure requirement. On the other hand, a non Red Hat CoreOS enabled location supports a smaller feature set but can run at a smaller footprint, allowing more clusters per same capacity. For more information, see [Sizing your Satellite location](https://cloud.ibm.com/docs/satellite?topic=satellite-location-sizing).

To verify if you location is enabled for Red Hat CoreOS, see [Is my location enabled for Red Hat CoreOS](https://cloud.ibm.com/docs/satellite?topic=satellite-locationsverify-coreos-location).

The bring your own key (BYOK) or keep your own key (KYOK) feature is supported in RHCOS enabled locations on Red Hat OpenShift on IBM Cloud 4.13 and later. It is supported on both RHEL and RHCOS hosts. You can encrypt only cluster secrets. This feature is not available during cluster or worker pool creation. You must run the ibmcloud oc kms enable command to enable it after the cluster or worker pool has been created. Note that this feature cannot be disabled after it is enabled.







 Deciding how to create your Satellite location 

Depending on your infrastructure provider, you have different options to create a Satellite location.



 On-premises infrastructure 

For on-prem infrastructure, you can manually setup a Satellite location. For more information, see [Manually creating Satellite locations](https://cloud.ibm.com/docs/satellite?topic=satellite-locationslocation-create-manual).





 Cloud provider infrastructure 

For cloud provider infrastructure, you can follow provider-specific guides. For more information, see [Creating a Satellite location](https://cloud.ibm.com/docs/satellite?topic=satellite-locations).







 Providing Satellite with credentials to your cloud provider
If you have more than 25 rules, IBM Cloud selects the first 25. You can manage these rules when editing your discovered resources.







 Gateway configurations not available in VPC 

If your IBM Cloud classic environment uses configurations in a gateway that are not available in VPC, VPC+ Cloud Migration sets the closest match to what is available for VPC or uses a default configuration.





 Considerations for IBM Cloud Kubernetes Service and Red Hat OpenShift migration 

With the VPC+ tool, you can discover and migrate your IBM Cloud Kubernetes Service or Red Hat® OpenShift® cluster from classic to IBM Cloud VPC. The VPC+ tool identifies all of your clusters and creates a workspace to help you manage your migration. You decide which cluster you want to migrate.

You can migrate the following versions:



* IBM Cloud Kubernetes Service version 1.21+
* Red Hat OpenShift version 4.6+



You can only migrate from a single data center to a single availability zone or multiple data centers to a multi-zone region.

The open source tools Velero and Restic are installed in their unique namespace by VPC+ to back up and migrate your IBM Cloud Kubernetes Service or Red Hat OpenShift resources and components such as cluster-level resources, worker pools, PODs, namespaces, secrets, stateful sets, daemon sets, replica sets, jobs, cron jobs, and persistent volumes.

You need to create an IBM Cloud Object Storage service credential with a manager service role and HMAC. A temporary Object Storage bucket is created in your account to assist with the migration. In addition, subnet gateways are to all IBM Cloud Kubernetes Service subnets.



 Limitations 

Review the following limitations for IBM Cloud Kubernetes Service or Red Hat OpenShift migration:



* Ingress resources and services are your responsibility.
* Only block volumes are supported.
* Velero requires 1 CPU and 500 MB for each node. In some cases, migration might fail due to hardware capacity. In these cases, scaling down resource consumption is required, such as disabling logging, monitoring, or applications.
No. When the IBM Blockchain Platform is configured with a multizone cluster in IBM Cloud Kubernetes service, you can choose which zone a particular component (peer or ordering node) is deployed to, or you can let the console decide. Then, when the node is subsequently deployed, Kubernetes "pins" the associated pod to the chosen zone. Pinning means that Kubernetes will not provision the pod in another zone in the event of a whole zone failure. And because the pods are pinned to specific zones, there is no need to access the same storage from another zone. Therefore, MZR storage is not required for IBM Blockchain Platform nodes.





 What versions of Red Hat OpenShift are supported? 

Currently, IBM Blockchain Platform for IBM Cloud supports linking to Red Hat OpenShift Container Platform 4.5, 4.6 and 4.7 clusters.





 Is there a trial option available for using a Red Hat OpenShift cluster on IBM Cloud? 

A free 30 day trial is available in the [Red Hat Marketplace.](https://marketplace.redhat.com/en-us/products/ibm-blockchain). See [Deploy from Red Hat Marketplace](https://cloud.ibm.com/docs/blockchain-sw-254?topic=blockchain-sw-254-deploy-ocp-rhm) to learn more.





 Is it possible to deploy blockchain nodes to multiple clouds from a single blockchain console? 

You cannot currently deploy blockchain nodes to multiple hosted cloud providers. However, you can use your console to operate a distributed multicloud network by importing nodes deployed by using consoles on other clouds.





 How can I find what version of the IBM Blockchain Platform that I am running? 

View the Support page by clicking the question mark icon ![Support link icon](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/blockchain/images/support-link.png) in the upper right corner of the page. The IBM Blockchain Platform version is visible under the page heading.
Therefore, the queries for hostnames within the VMware instance's root zone are handled by the AD DNS server that is running within your VMware environment.



Alternately, you can configure your local hosts file with the following entries so you can access the Red Hat OpenShift web console. Use the following details for the example.



* Replace APPLICATION_IP with the Red Hat OpenShift application IP address shown in the Red Hat OpenShift service details page.
* Replace ROOTDOMAIN with the root domain shown on the Summary page for the vCenter Server instance.

APPLICATION_IP console-openshift-console.apps.ocp.ROOTDOMAINAPPLICATION_IP oauth-openshift.apps.ocp.ROOTDOMAIN







 Related links 



* [Ordering services for vCenter Server instances](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_addingservices)
* [Contacting IBM Support](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-trbl_support)
* [FAQ](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-faq-vmwaresolutions)
For more information, see [Allowing Red Hat OpenShift on IBM Cloud to access other IBM Cloud resources by using CBR](https://cloud.ibm.com/docs/openshift?topic=openshift-cbr&interface=clicbr-integrations).

Review the [limitations](https://cloud.ibm.com/docs/openshift?topic=openshift-cbr&interface=clicbr-limitations) before you create network zones.



 Creating network zones from the API 

You can create network zones by using the /v1/zones API. For more information, see the [API docs](https://cloud.ibm.com/apidocs/context-based-restrictionscreate-zone). You can add the containers-kubernetes service to your network zones to allow Red Hat OpenShift on IBM Cloud to access resources and services in your account.

You can include multiple address types in your network zone payload. For more information, see the example payload in the [API docs](https://cloud.ibm.com/apidocs/context-based-restrictionscreate-zone).

Example payload to add Red Hat OpenShift on IBM Cloud to a network zone. The serviceRef attribute for Red Hat OpenShift on IBM Cloud is containers-kubernetes.

{
"name": "Example zone 1",
"description": "",
"addresses": [
{
"type": "serviceRef",
"ref": {
"service_name": "containers-kubernetes",
"account_id": "ACCOUNT-ID"
}
}
]
}

Example payload to add multiple services, IP addresses, and VPCs to a network zone.

{
"name": "zone",
"description": "",
"addresses": [
{
"type": "ipAddress",
"value": "192.168.0.0"
},
{
"type": "vpc",
For more information, see [Allowing Red Hat OpenShift on IBM Cloud to access other IBM Cloud resources by using CBR](https://cloud.ibm.com/docs/openshift?topic=openshift-cbr&interface=uicbr-integrations).

Review the [limitations](https://cloud.ibm.com/docs/openshift?topic=openshift-cbr&interface=uicbr-limitations) before you create network zones.



 Creating network zones from the API 

You can create network zones by using the /v1/zones API. For more information, see the [API docs](https://cloud.ibm.com/apidocs/context-based-restrictionscreate-zone). You can add the containers-kubernetes service to your network zones to allow Red Hat OpenShift on IBM Cloud to access resources and services in your account.

You can include multiple address types in your network zone payload. For more information, see the example payload in the [API docs](https://cloud.ibm.com/apidocs/context-based-restrictionscreate-zone).

Example payload to add Red Hat OpenShift on IBM Cloud to a network zone. The serviceRef attribute for Red Hat OpenShift on IBM Cloud is containers-kubernetes.

{
"name": "Example zone 1",
"description": "",
"addresses": [
{
"type": "serviceRef",
"ref": {
"service_name": "containers-kubernetes",
"account_id": "ACCOUNT-ID"
}
}
]
}

Example payload to add multiple services, IP addresses, and VPCs to a network zone.

{
"name": "zone",
"description": "",
"addresses": [
{
"type": "ipAddress",
"value": "192.168.0.0"
},
{
"type": "vpc",
: Updated the [ingress-auth image build to 413](https://cloud.ibm.com/docs/containers?topic=containers-cluster-add-ons-changelogkube_ingress_changelog).





 23 June 2020 

New! Red Hat OpenShift on IBM Cloud observability plug-in
: You can now use the Red Hat OpenShift on IBM Cloud observability plug-in to create a logging or monitoring configuration for your cluster so that you can forward cluster logs and metrics to an IBM Log Analysis and IBM Cloud Monitoring service instance. For more information, see [Forwarding cluster and app logs to IBM Log Analysis](https://cloud.ibm.com/docs/openshift?topic=openshift-healthopenshift_logging) and [Forwarding cluster and app metrics to IBM Cloud Monitoring](https://cloud.ibm.com/docs/openshift?topic=openshift-health-monitor). You can also use the command line to create the logging and monitoring configuration. For more information, see the [Observability plug-in CLI](https://cloud.ibm.com/docs/openshift?topic=openshift-observability_cli) reference.





 22 June 2020 

Version change logs
: Change log documentation is available.
: Red Hat OpenShift [4.3.13_1522_openshift master and 4.3.25_1527_openshift worker node](https://cloud.ibm.com/docs/openshift?topic=openshift-changelog_archive4323_1527_master) and [3.11.219_1554_openshift master and 3.11.232_1554_openshift worker node](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_311311219_1554_master) fix pack patch updates.





 18 June 2020 

Ingress ALB change log
* Red Hat OpenShift Container Platform: Create a cluster in an IBM Cloud VPC. You can specify the version and cluster size.
* Worker pools: Creates worker pools in a container platform. With worker pools, you can group and manage worker nodes with similar configurations, such as compute resources and availability zones.
* Subnets for containers: Configures subnets for the cluster, and specifies the subnets to deploy the worker nodes in.
* Private and public endpoints: Configures private and public endpoints for the cluster.
* Ingress configuration: Configures the ingress controller for the cluster. The controller is responsible for routing external traffic to the appropriate services within the cluster.



For more information about the concepts of using Red Hat OpenShift Container Platform on VPC, see this [reference architecture](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-detailed-openshift) from the IBM Cloud for Financial Services docs.
After you create and run your Function, you can also update your Function by using any of the preceding ways, independent of how you created or previously updated your Function.





 Requests and responses 

Functions are invoked with the HTTP protocol. When you invoke your Function, you can specify the custom request parameters, custom request body and headers, as well as the HTTP method. The request parameters are made available to the Function code as input parameters. The Function code can set the response body, response headers, and response code, which are returned to the caller from the Functions endpoint.



 Example 1: Generating an HTML response from a Function 

The following example illustrates how to generate an HTML response from a Function.

function main(params) {
var msg = 'You did not tell me who you are.';
if (params.name) {
msg = Hello, ${params.name}!
} else {
msg = Hello, FaaS on CodeEngine!
}
return {
headers: { 'Content-Type': 'text/html; charset=utf-8' },
body: <html><body><h3>${msg}</h3></body></html>
}
}

module.exports.main = main;





 Example 2: Setting a response code and response header 

Your Function can set a specific response code and header flags. The following example illustrates how you can set a response code and response header to add a redirect to a different URL.

function main(params) {
return {
headers: { location: 'https://cloud.ibm.com/docs/codeengine' },
statusCode: 302
}
}





 Example 3: Generating a plain text response from a Function 

The following example illustrates how to generate a plain text response from a Function.

function main(params) {
var msg = 'You did not tell me who you are.';
if (params.name !== "") {
msg = Hello, ${params.name}!
}