vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* Node-RED Operator: https://github.com/IBM-Cloud/operator-bundle-sample/archive/refs/tags/v0.0.3.tar.gz
* Operator bundle from a Red Hat OpenShift on IBM Cloud registry: For an example, select the Akka Cluster Operator from the list of available Operators in the Certified repository.
* OVA image: https://github.com/gcatalog/OVA-sample/blob/main/ova-sample.yaml
* Terraform template: https://github.com/IBM-Cloud/terraform-sample/archive/refs/tags/v1.1.0.tar.gz
* Virtual server image with Terraform: https://github.com/IBM-Cloud/isv-vsi-product-deploy-sample/releases/download/v1.0/isv-vsi-product-deploy-sample.tar.gz
* Virtual server image for VPC: Select an image from the list of available images that were imported into your VPC, or import a new image to your account.



A virtual server image for VPC can only be added to one product within one private catalog at a time. If the virtual server image you want to import is already imported into another product, you must remove the image from that product or delete the product before you add the virtual server image to a new product.

If you're adding your product from a private repository, you can choose to provide a personal access token or you can use a secret. Instead of giving users a personal access token, you can give them access to a secret, add the token to a secret, and centrally manage all tokens and access the secret allows.



* If you're using a personal access token, select No to indicate that you aren't using a secret and provide your personal access token.
* If you're using a secret, select Yes and click Select from Secrets Manager. Select your service instance, secret group, and secret. If you don't see your secret, make sure you're using the correct secret group and service instance.
The location consists of a region and a zone.

The region that you select is used as the region of the VPC. All additional resources that you create in this VPC are created in the selected region.
4. Enter an Address prefix, Number of addresses, and an IP range for the subnet. The IP range is entered in CIDR notation, for example: 10.240.0.0/24. In most cases, you can use the default IP range. If you want to specify a custom IP range, you can use the IP range calculator to select a different address prefix or change the number of addresses.

A subnet cannot be resized after it has been created.
5. Attach a public gateway to the subnet if you want to allow all attached resources to communicate with the public internet.

You can also attach the public gateway after you create the subnet.
6. Click Create virtual private cloud.







 Manually defining your subnets 

If you disabled Default address prefixes, which hid the New subnet for VPC section on the VPC ordering page, you need to manually define your subnets before provisioning your Virtual Servers for VPC. Use the following steps to set up your subnets if you didn't do so when you set up your VPC.



1. Click Menu icon![Menu icon](https://cloud.ibm.com/docs-content/v1/content/icons/icon_hamburger.svg) > VPC Infrastructure > Subnets > New Subnet.
2. Enter a unique Name and select the Virtual private cloud that it's to be associated with.
3. Select a Resource group.
4. Select Location. The location consists of a region and zone. If you're manually creating the initial subnet, versus creating it when you created your VPC, the region (location) that you select is used as the region of the VPC. All additional resources that you in this VPC are created in the selected region.

If you created a subnet when you created your VPC, more subnets must be created in the same region. You can create multiple subnets within VPC zones.
5.
A region is also often referred to a multizone region or MZR.

A zone is an abstraction that refers to the physical data center, which hosts the compute, network, storage resources, and the related cooling and power, which provides services and applications. Zones are isolated from each other, so to create no shared single point of failure, improved fault tolerance, and reduced latency. Each zone is assigned a default address prefix, which specifies the range of addresses in which subnets can be created. If the default address scheme does not suit your requirements, such as if you want to bring your own public IPv4 address range, you can customize the address prefixes. A zone is also known as an availability zone or AZ.

Virtual Private Clouds or VPCs are deployed to a single region. Within that region, the VPC can span multiple zones. You can have multiple VPCs in your IBM Cloud account.

Subnets within the VPC offer private connectivity. They can communicate to each other over a private link by using the implicit router. Setting up routes is not necessary. Subnets are provisioned from prefixes, which are defined per zone and assigned to IBM Cloud virtual server or bare metal server instance vNICs.

Subnets in your VPC can connect to the public internet through an optional public gateway. You can assign floating IP addresses to any virtual server or bare metal server instance vNICs to enable it to be reachable from the internet, independent of whether its subnet is attached to a public gateway. Floating IP addresses can be either NATed to private VPC subnet IPs, or routed to NSX-T logical routers without NAT. Currently, only one or more single IP addresses can be routed, but as the solution develops, it's possible to route entire subnets. When the VPC NAT is disabled, the packet is passed unmodified to or from the network interface, allowing for instance the NSX-T logical routers to perform any needed NAT or routing operations. This capability can also be used with public IP addresses assigned to NSX-T overlay services and later with subnets on NSX-T segments.

An Access Control List (ACL) can allow or deny inbound and outbound traffic for a subnet.
Types of network load balancers 

Network Load Balancer for VPC supports public, private, and private-type with routing mode enabled.

A public load balancer is a load balancer with a publicly accessible IP address that is registered with DNS. A private load balancer is a load balancer only accessible from within the VPC network and/or where the client has reachability to the VPC network (for example, through Direct Link or Transit Gateway).

For private load balancers, you must have a dedicated subnet with no custom routes configured for the subnet.

Network load balancers with route_mode set to true are private load balancers that support only VNF (virtual network function) devices as back-end targets.





 Load-balancing methods 

Three load-balancing methods are available for distributing traffic across back-end application servers: round-robin, weighted round-robin, and least connections.



 Round-robin 

Round-robin is the default load-balancing method. With this method, the load balancer forwards incoming client connections in a round-robin fashion to the back-end servers. As a result, all back-end servers receive roughly an equal number of client connections.





 Weighted round-robin 

With this method, the load balancer forwards incoming client connections to the back-end servers in proportion to the weight assigned to these servers. Each server is assigned a default weight of 50, which can be customized to any value in the range 0 - 100.

For example, if application servers A, B, and C have the weights 60, 60, and 30, then servers A and B receive an equal number of connections, while server C receives half that number of connections.

Setting a server weight to 0 means that no new connections are forwarded to that server, but any existing traffic continues to flow. Using a weight of 0 can help bring down a server gracefully and remove it from service rotation.

The server weight values are applicable only with the weighted round-robin method. They are ignored with the round-robin and least connections load-balancing methods.





 Least connections 

With this method, the back-end server instance that serves the least number of connections at a given time receives the next client connection.







 Use case 1: High traffic volume
Why does the Ingress status show an ERRAHCF error? 

Virtual Private Cloud

Classic infrastructure

You can use the the ibmcloud ks ingress status-report ignored-errors add command to add an error to the ignored-errors list. Ignored errors still appear in the output of the ibmcloud ks ingress status-report get command, but are ignored when calculating the overall Ingress Status.

 What’s happening 

When you check the status of your cluster's Ingress components by running the ibmcloud ks ingress status-report get command, you see an error similar to the following example.

The ALB is unable to respond to health requests (ERRAHCF).

 Why it’s happening 

IBM Cloud Kubernetes Service deploys an application into your cluster that checks whether your ALBs can respond to HTTPS requests. The application reports problems getting replies from one or more ALBs on your cluster.

 How to fix it 

Review your access control lists to make sure that health traffic is allowed.



1. List your cluster ALBs using the following command.

ibmcloud ks ingress alb ls
2. Make a note of the load balancer address.



* VPC clusters: Make a note of the address in the Load Balancer Hostname column.
* Classic clusters: Make a note of the address in the ALB IP column.



3. Get your cluster details running the following command. Make a note of your Ingress subdomain.

ibmcloud ks cluster get
4. Check that the ALB responds to health requests by running the following command. Enter the load balancer address and Ingress subdomain that you retrieved earlier.

curl https://LOAD-BALANCER-ADDRESS -H "Host: albhealth.INGRESS-SUBDOMAIN"
5. Ensure that no firewall rules or access control lists are blocking communication between the health checker application and your ALBs.



* VPC clusters: Health check traffic originates from one of the worker nodes, flows through a VPC Public Gateway and arrives to the public side of the VPC Load Balancer instance. Configure your VPC Security Groups to allow this communication.
Planning for virtual private endpoint gateways 

Before you create a virtual private endpoint gateway, review the following considerations.



*  A reserved IP address that is bound to an endpoint gateway can receive traffic from another zone of the same VPC if your Network ACL (NACL) allows it.
*  You can bind only one IP address per VPC zone to an endpoint gateway.
*  You can attach up to five security groups when you create a VPE. If you do not specify a security group during VPE creation, the default security group for your VPC is used.

If you do not select at least one security group, it is recommended that you update your default security group rules to minimize disruption in traffic on a newly created VPE.
*  You can create a security group before provisioning (or during provisioning in the UI).



*  The security group must be created in the same VPC as your VPE.
*  Configure inbound rules that define what type of traffic is allowed to the VPE. For each rule, complete the following information:



*  Specify a CIDR block or IP address for the permitted inbound traffic. Alternatively, you can specify a security group in the same VPC to allow traffic to all sources that are attached to the selected security group.
*  Select the protocols and ports to which the rule applies.





*  You can access IBM Cloud® services by using either VPEs or the service endpoint directly. However, if you want your VPC to enforce a certain behavior or discipline, it is recommended to block direct access to the service endpoint IP addresses that use NACLs. For more information, see [Configuring ACLs and security groups for use with endpoint gateways](https://cloud.ibm.com/docs/vpc?topic=vpc-configure-acls-sgs-endpoint-gateways).

IBM Cloud services do not support accessing a service endpoint and VPE simultaneously from the same virtual instance.
7. Remove the private IP addresses from your cluster's subdomain. Repeat this command for all private IP addresses that you retrieved earlier.

ibmcloud oc nlb-dns rm classic --ip <private_IP> --cluster <cluster_name_or_ID> --nlb-host <hostname>
8. Verify that the public IP addresses are registered with your cluster subdomain.

ibmcloud oc nlb-dns ls --cluster <cluster_name_or_ID>









 Accessing VPC clusters through the Virtual Private Endpoint Gateway 

[Virtual Private Endpoint Gateway](https://cloud.ibm.com/docs/vpc?topic=vpc-about-vpe) is created for VPC clusters automatically. The Kubernetes master is accessible through this Virtual Private Endpoint gateway if authorized cluster users are connected to the same VPC where the cluster is deployed, such as through a [IBM Cloud VPC VPN](https://cloud.ibm.com/docs/vpc?topic=vpc-vpn-overview). In this case, the kubeconfig is configured with the Virtual Private Endpoint (VPE) URL which is a private DNS name and can be resolved only by the IBM Cloud VPC Private DNS service. The IBM Cloud VPC Private DNS server addresses are 161.26.0.7 and 161.26.0.8.

For clusters that run version 4.13 or later: If you enabled only the private cloud service endpoint during cluster creation, the virtual private endpoint of your VPC is used by default to access Red Hat OpenShift components such as the Red Hat OpenShift web console or OperatorHub. You must be connected to the private VPC network, such as through a VPN connection, to access these components or run kubectl commands on your cluster. Note that to access the console through the VPE, you must be able to access cloud.ibm.com, which requires public connectivity.



1. Set up your IBM Cloud VPC VPN and connect to your VPC through VPN.



1.
* If the worker nodes are in a different infrastructure account: Use the ibmcloud ks credential set[command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_credentials_set) to change your infrastructure credentials to the account that the cluster worker nodes are provisioned in, which you found in the previous step.

If you no longer have access to the infrastructure credentials, you can open an IBM Cloud support case to determine an email address for the administrator of the other infrastructure account. However, IBM Cloud Support can't remove the orphaned cluster for you, and you must contact the administrator of the other account to get the infrastructure credentials.
* If the infrastructure accounts match: Check the rest of the worker nodes in the cluster and see if any are assigned to different infrastructure account. Make sure that you checked the worker nodes in the cluster that have the credentials issue. Review other [common infrastructure credential issues](https://cloud.ibm.com/docs/containers?topic=containers-cluster_infra_errors).



6. Now that the infrastructure credentials are updated, retry the blocked action, such as updating or deleting a worker node, and verify that the action succeeds.
7. If you have other clusters in the same region and resource that require the previous infrastructure credentials, repeat Step 3 to reset the infrastructure credentials to the previous account. Note that if you created clusters with a different infrastructure account than the account that you switch to, you might orphan those clusters.

Tired of switching infrastructure accounts each time you need to perform a cluster or worker action? Consider re-creating all the clusters in the region and resource group in the same infrastructure account. Then, migrate your workloads and remove the old clusters from the different infrastructure account.







 Unable to create or delete worker nodes due to endpoints error 

 What’s happening 

You can't manage worker nodes for your cluster, and you receive an error message similar to one of the following.

Worker deploy failed due to network communications failing to master or registry endpoints. Please verify your network setup is allowing traffic from this subnet then attempt a worker replace on this worker

Pending endpoint gateway creation

 Why it’s happening
If you are using actions in your assistant, follow these steps to disable autocorrection:



1. On the Actions page, click Global settings !![Gear icon](https://cloud.ibm.com/docs-content/v1/content/icons/settings.svg).
2. Click the Autocorrection tab.
3. Set the switch to Off, then click Save.



If you are using dialog in your assistant, follow these steps to disable autocorrection:



1. In the Options section, click Autocorrection.
2. Set the switch to Off.







 Testing autocorrection in dialog 

If you are using dialog, you can test autocorrection using Try it out.



1. In Try it out, enter a request that includes some misspelled words.

If words in your input are misspelled, they are corrected automatically, and an ![auto-correct](https://cloud.ibm.com/docs-content/v1/content/417db917d18067d9dcc4cf2612564a9a87c3ddc8/assistant/images/auto-correct.png) icon is displayed. The corrected utterance is underlined.
2. Hover over the underlined utterance to see the original wording.



If there are misspelled terms that you expected your assistant to correct, but it did not, then review the rules that your assistant uses to decide whether to correct a word to see if the word falls into the category of words that your assistant intentionally does not change.





 Autocorrection rules 

To avoid overcorrection, your assistant does not correct the spelling of the following types of input:



* Capitalized words
* Emojis
* Locations, such as states and street addresses
* Numbers and units of measurement or time
* Proper nouns, such as common first names or company names
* Text within quotation marks
* /usr/sap/<SAPSID>/Dxx



* Permanent NFS mount on SAP Apps HA node 2 dialog instance:



* /usr/sap/<SAPSID>/Dyy







 Prerequisites 

You need to install the hardware (hosts, disks, and network) and decide how to distribute the database, SAP instances, and, if required, the Network File System (NFS) server over the cluster nodes.





 Context 

From the perspective of an SAP application, there are the following types of SAP directories:



* Physically shared directories: /<sapmnt>/<SAPSID> and /usr/sap/trans
* Logically shared directories that are bound to a node, such as /usr/sap, with the following local directories:



* /usr/sap/<SAPSID>
* /usr/sap/<SAPSID>/SYS
* /usr/sap/hostctrl



* Local directories that contain the SAP instances, such as /usr/sap/<SAPSID>/ASCS<Instance_Number>
* The global transport directory might reside on a separate SAP transport host as a standard three systems transport layer configuration.



You need at least two nodes and a shared file system for distributed ASCS and ERS instances, and the assumption is that the rest of the components are distributed on other nodes.





 ASCS and ERS installation 

In order for the ASCS and ERS instances to be able to move from one node to the other, they need to be installed on a shared file system and use virtual hostnames based on the virtual IP.

In this VPC-based SAP HA solution, the shared file system that is required by the cluster is replaced by the NFS-mounted file storage, and the virtual IP is replaced by the Application Load Balancer for VPC (ALB).

In this scenario, three ALBs are used, one for each Single Point of Failure component (SPOF) in order to replace the virtual IP requirement: ALB for ASCS, ALB for ERS, and ALB for HANA.
A policy assigns a user one or more roles that define the scope of access to a single service or to a set of services and resources that are organized together in a resource group. Each service in IBM Cloud might require its own set of access policies.



 Pick the correct access policy and role for your users 

You must define access policies for every user that works with IBM Cloud Kubernetes Service. The scope of an access policy is based on a user's defined role or roles, which determine the actions that the user can perform. Some policies are pre-defined but others can be customized. The same policy is enforced whether the user makes the request from the IBM Cloud API, CLI, or UI.

The following image shows the different types of permissions and roles, the actions a role can perform, and how the roles relate to each other.

Zoom

![In IBM Cloud, you can assign IAM platform, IAM service, Cloud Foundry, and infrastructure roles.](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/user_access.png)

Figure 1. Assign IAM platform, IAM service, Cloud Foundry, and infrastructure roles

To see the specific IBM Cloud Kubernetes Service permissions that can be performed with each role, check out the [User access permissions](https://cloud.ibm.com/docs/containers?topic=containers-access_reference) reference topic.



 Overview of IBM Cloud IAM platform access roles 

Use platform access roles in IBM Cloud Identity and Access Management (IAM) to grant users access to manage cluster resources in IBM Cloud Kubernetes Service. When you configure permissions for IBM Cloud Kubernetes Service in IAM, use the name containers-kubernetes for the API or CLI, and Kubernetes Service for the console.

What types of actions do platform access roles permit?
: With platform access roles, users can manage resources like clusters, worker pools, worker nodes, and add-ons.
Depending on the purpose of the webhook, it might be important that the webhook be called for all namespaces. Review the namespaceSelector configuration options in the [Kubernetes documentation](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/matching-requests-namespaceselector) and adjust your webhook configuration.
* Make sure that the worker nodes in your cluster are [the correct size for running your webhook applications](https://cloud.ibm.com/docs/openshift?topic=openshift-strategysizing). For example, if your pods request more CPU or memory than the worker node can provide, the pods are not scheduled.







 What other types of apps use admission controllers? 

Many cluster add-ons, plug-ins, and other third-party extensions use admission controllers. Some common ones include:



* [Portieris](https://cloud.ibm.com/docs/openshift?topic=openshift-imagesportieris-image-sec)







 I need help with a broken webhook. What can I do? 

For help troubleshooting webhooks, see [Debugging webhooks](https://cloud.ibm.com/docs/openshift?topic=openshift-ts-webhook-debug) or [Cluster can't update because of broken webhook](https://cloud.ibm.com/docs/openshift?topic=openshift-webhooks_update).