vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Using IAM IP address access restrictions with Event Streams 

If you want to enable [IAM IP address access restrictions](https://cloud.ibm.com/docs/account?topic=account-ips), you must ensure that the Cloud Identity and Access Management (IAM) IP allowlist is configured so that the Event Streams authentication and authorization service, which is used to authenticate and authorize the Kafka client, can still function.

Using the Event Streams Satellite plan with the IP address restrictions is not yet supported. Although you can enable IP address restrictions in your account, Event Streams Satellite plan clusters do not accept messages. Support for co-existence is in plan. As a workaround, provision Event Streams Satellite plan clusters from a separate account.



 Granting access if you use Event Streams over the public network 

If you use Event Streams over the public network, you must add the IP addresses of any computers that access Kafka API endpoints and REST API endpoints to the Cloud Identity and Access Management (IAM) IP allowlist.





 Granting access if you use Event Streams over the private network (Enterprise plan only) 

If you use Event Streams over the private network, you must add the Event Streams's own private IP addresses for the appropriate cluster to the Cloud Identity and Access Management (IAM) IP allowlist. You can find these IP addresses with the following command:

ibmcloud resource service-instance <event-streams-instance-name> --output json

Find the extensions.virtual_private_endpoints.endpoints.ip_address section from the output, add the three 166.9.x.x IP addresses to the Cloud Identity and Access Management (IAM) IP allowlist, as in the following example. These addresses are static and remain for the life of the service instance.

{
"extensions": {
"virtual_private_endpoints": {
"dns_domain": "private.us-south.messagehub.appdomain.cloud",
"dns_hosts": [
"kafka-0-mh-int-pipe-mis-cfxdrmzjgs",
* API keys for users and service IDs continue to work after MFA is enabled.
* MFA for your account applies to a user's login, but does not apply to API calls. If a user has permission to make API calls to resources in your account, the user can do so without completing MFA. If the user belongs to other accounts, the user can make API calls to resources in your account by using an API key from an account that did not require MFA.
* Plan a communication and support strategy for users in your account:



* Choose a date and time that you plan to enable MFA that results in the least impact to your business.
* Notify the users in your account after you enable MFA with information on how to get set up.





When you set the ID-based account default MFA, all IBMid users in your account are prompted for IBMid MFA authentication upon login. If you have other MFA factors set up for any IBMid users in your account, they are no longer prompted for those MFA factors. For example, if you previously enabled security questions in the customer portal for your classic infrastructure resources, the MFA account setting overrides the security questions option.

You can also enable and disable MFA in your account on the [Verification methods and authentication factors](https://iam.cloud.ibm.com/mysecurity) page by clicking Show accounts > Manage your own account.





 Enabling MFA 

Enabling MFA does not affect users that are already logged in because MFA takes effect only at the time of login. Make sure that you notify your account users that MFA is enabled, and describe the impact to users at their next login.

The first time that you log in to your account after MFA settings are updated, you need to verify your identity by using two different verification methods. Methods for verification include email, text, or phone call, and you can use any combination of those options to verify your identity. After you verify your identity, you set up your authentication factors. If you need to update your verification methods or authentication factors later, see [Managing verification methods and MFA factors](https://cloud.ibm.com/docs/account?topic=account-verification-authentication).



 Enabling MFA for an account 



1.
To change the [language](https://cloud.ibm.com/docs/appid?topic=appid-cd-typescd-languages) of the message, you can use [the APIs](https://us-south.appid.cloud.ibm.com/swagger-ui//Management%20API%20-%20Config/mgmt.updateLocalization) to set the language. However, you are responsible for the content and conversion of the message. Check out the following table to see the list of tables that you can use in this message and all the other messages that you can send. If a user does not supply the information that is pulled by the parameter, it appears blank.
4. Click Save.







 Email: Verification 

When a user signs up for your application by using their email, you can send them an email that asks them to confirm their identity. By requesting a verification, you limit the number of fake accounts that can sign up for your app. You can restrict access to your app until a user verifies their email, or use it as a way to manage which users you create profiles for.

Users who are manually added via the App ID dashboard or the create user API do not automatically receive this email.



1. Go to the Cloud Directory > Email templates > Email verification tab of the service dashboard.
2. Set Email verification to Enabled.
3. Set Allow users to sign in to your app without first verifying their email address to Yes. When set to yes, users are able to interact with your application after they sign up, but before they verify their email address. The default setting is no.
4. Customize the content of your message. You can add parameters and insert images by using the UI.
Use the [IngressClass](https://kubernetes.io/docs/concepts/services-networking/ingress/ingress-class) resource to customize Ingress classes.





 Adding App ID authentication to apps 

Enforce authentication for your apps by configuring Ingress with [IBM Cloud App ID](https://cloud.ibm.com/catalog/services/app-id).



1. Choose an existing or create a new App ID instance.

An App ID instance can be used in only one namespace in your cluster. If you want to configure App ID for Ingress resources in multiple namespaces, repeat the steps in this section to specify a unique App ID instance for the Ingress resources in each namespace.



* To use an existing instance, ensure that the service instance name contains only lowercase alphanumeric characters or hyphens (-), and doesn't contain spaces. To change the name, select Rename service from the more options menu on your service instance details page.
* To provision a [new App ID instance](https://cloud.ibm.com/catalog/services/app-id):



1. Replace the Service name with your own unique name for the service instance. The service instance name must contain only lowercase alphanumeric characters or hyphens (-), and can't contain spaces.
2. Choose the same region that your cluster is deployed in.
3. Click Create.





2. Add redirect URLs for your app. A redirect URL is the callback endpoint of your app. To prevent phishing attacks, IBM Cloud App ID validates the request URL against the allowlist of redirect URLs.



1. In the App ID management console, navigate to Manage Authentication.
2. In the Identity providers tab, make sure that you have an Identity Provider selected. If no Identity Provider is selected, the user will not be authenticated but will be issued an access token for anonymous access to the app.
3.
(https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.mdhow-does-scale-up-work) and [How does scale-down work?](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.mdhow-does-scale-down-work).

Can I change how scale-up and scale-down work?
: You can customize settings or use other Kubernetes resources to affect how scaling up and down work.

Scale-up
: [Customize the cluster autoscaler ConfigMap values](https://cloud.ibm.com/docs/containers?topic=containers-cluster-scaling-enablecluster-scaling-customize) such as scanInterval, expander, skipNodes, or maxNodeProvisionTime. Review ways to [overprovision worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-cluster-scaling-deploy-appsca_scaleup) so that you can scale up worker nodes before a worker pool runs out of resources. You can also [set up Kubernetes pod budget disruptions and pod priority cutoffs](https://cloud.ibm.com/docs/containers?topic=containers-cascalable-practices-apps) to affect how scaling up works.

Scale-down
: [Customize the cluster autoscaler ConfigMap values](https://cloud.ibm.com/docs/containers?topic=containers-cluster-scaling-enablecluster-scaling-customize) such as scaleDownUnneededTime, scaleDownDelayAfterAdd, scaleDownDelayAfterDelete, or scaleDownUtilizationThreshold.

Can I increase the minimum size per zone to trigger a scale up my cluster to that size?
: No, setting a minSize does not automatically trigger a scale-up. The minSize is a threshold so that the cluster autoscaler does not scale to fewer than a certain number of worker nodes per zone.
(https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.mdhow-does-scale-up-work) and [How does scale-down work?](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.mdhow-does-scale-down-work).

Can I change how scale-up and scale-down work?
: You can customize settings or use other Kubernetes resources to affect how scaling up and down work.

Scale-up
: [Customize the cluster autoscaler ConfigMap values](https://cloud.ibm.com/docs/containers?topic=containers-cluster-scaling-enablecluster-scaling-customize) such as scanInterval, expander, skipNodes, or maxNodeProvisionTime. Review ways to [overprovision worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-cluster-scaling-deploy-appsca_scaleup) so that you can scale up worker nodes before a worker pool runs out of resources. You can also [set up Kubernetes pod budget disruptions and pod priority cutoffs](https://cloud.ibm.com/docs/containers?topic=containers-cluster-scaling-classic-vpcscalable-practices-apps) to affect how scaling up works.

Scale-down
: [Customize the cluster autoscaler ConfigMap values](https://cloud.ibm.com/docs/containers?topic=containers-cluster-scaling-enablecluster-scaling-customize) such as scaleDownUnneededTime, scaleDownDelayAfterAdd, scaleDownDelayAfterDelete, or scaleDownUtilizationThreshold.

Can I increase the minimum size per zone to trigger a scale up my cluster to that size?
: No, setting a minSize does not automatically trigger a scale-up. The minSize is a threshold so that the cluster autoscaler does not scale to fewer than a certain number of worker nodes per zone.
Why doesn't my cluster add-on work? 

  What’s happening 

When you try to use a cluster add-on in IBM Cloud Satellite®, the cluster add-on does not work. For example, you installed the Kubernetes web terminal add-on but cannot open the add-on.

  Why it’s happening 

Add-ons might not work for several reason.



*  The add-on is not supported for clusters in a Satellite location.
*  The add-on is in an unhealthy state.
*  The add-on settings are misconfigured, such as renaming or editing a ConfigMap.
*  The add-on cannot be backed up in IBM Cloud Object Storage due to conflicting service instance and bucket endpoints.



  How to fix it 

Take the following steps to troubleshoot the add-on.



1.  Check that the [add-on is supported](https://cloud.ibm.com/docs/openshift?topic=openshift-managed-addonsaddons-satellite). If not, uninstall the add-on.
2.  If the add-on is misconfigured, refresh the cluster master to restore the add-on to the default settings.

ibmcloud oc cluster master refresh -c <cluster_name_or_ID>
3.  If the add-on is in critical state, review the IBM Cloud Object Storage instance and bucket that backs up the cluster data. The instance and endpoint must have matching endpoints, such as a Global instance with a Cross Region bucket (us-geo endpoint), or a Regional instance with a Regional bucket (us-east endpoint). If the endpoints do not match, you must re-create the Satellite location with matching IBM Cloud Object Storage instance and bucket endpoints.
4.  For more information, [review the add-on state and statuses](https://cloud.ibm.com/docs/openshift?topic=openshift-debug_addons).
To see how Watson Assistant is helping enterprises cut costs and improve customer satisfaction today, read the [Independent study finds IBM Watson Assistant customers can accrue $23.9 million in benefits](https://www.ibm.com/blogs/watson/2020/03/independent-study-finds-ibm-watson-assistant-customers-accrued-23-9-million-in-benefits/) blog on ibm.com.

Read more about these implementation steps by following these links:



* [Building your assistant](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-build-actions-overview)
* [Publishing and deploying your assistant](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-publish-overview)







 Browser support 

The Watson Assistant application requires the same level of browser software as is required by IBM Cloud. For more information, see IBM Cloud [Prerequisites](https://cloud.ibm.com/docs/overview?topic=overview-prereqs-platformbrowsers-platform).

For information about the web browsers that are supported by the web chat integration, see [Browser support](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-web-chat-architectureweb-chat-architecture-browsers).





 Language support 

Language support by feature is detailed in [Supported languages](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-admin-language-supportadmin-language-support-codes).
(https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.mdhow-does-scale-up-work) and [How does scale-down work?](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.mdhow-does-scale-down-work).

Can I change how scale-up and scale-down work?
: You can customize settings or use other Kubernetes resources to affect how scaling up and down work.

Scale-up
: [Customize the cluster autoscaler ConfigMap values](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-enablecluster-scaling-customize) such as scanInterval, expander, skipNodes, or maxNodeProvisionTime. Review ways to [overprovision worker nodes](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-deploy-appsca_scaleup) so that you can scale up worker nodes before a worker pool runs out of resources. You can also [set up Kubernetes pod budget disruptions and pod priority cutoffs](https://cloud.ibm.com/docs/openshift?topic=openshift-cascalable-practices-apps) to affect how scaling up works.

Scale-down
: [Customize the cluster autoscaler ConfigMap values](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-enablecluster-scaling-customize) such as scaleDownUnneededTime, scaleDownDelayAfterAdd, scaleDownDelayAfterDelete, or scaleDownUtilizationThreshold.

Can I increase the minimum size per zone to trigger a scale up my cluster to that size?
: No, setting a minSize does not automatically trigger a scale-up.
(https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.mdhow-does-scale-up-work) and [How does scale-down work?](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.mdhow-does-scale-down-work).

Can I change how scale-up and scale-down work?
: You can customize settings or use other Kubernetes resources to affect how scaling up and down work.

Scale-up
: [Customize the cluster autoscaler ConfigMap values](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-enablecluster-scaling-customize) such as scanInterval, expander, skipNodes, or maxNodeProvisionTime. Review ways to [overprovision worker nodes](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-deploy-appsca_scaleup) so that you can scale up worker nodes before a worker pool runs out of resources. You can also [set up Kubernetes pod budget disruptions and pod priority cutoffs](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-classic-vpcscalable-practices-apps) to affect how scaling up works.

Scale-down
: [Customize the cluster autoscaler ConfigMap values](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-enablecluster-scaling-customize) such as scaleDownUnneededTime, scaleDownDelayAfterAdd, scaleDownDelayAfterDelete, or scaleDownUtilizationThreshold.

Can I increase the minimum size per zone to trigger a scale up my cluster to that size?
: No, setting a minSize does not automatically trigger a scale-up.
If any node is over 80% in either CPU or memory usage, consider provisioning more nodes or reducing your workload.

kubectl top node

Example output.

NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
10.001.1.01 640m 16% 6194Mi 47%
10.002.2.02 2686m 68% 4024Mi 30%
10.003.3.03 2088m 53% 10735Mi 81%
2. Make sure that you have [removed any added webhooks](https://cloud.ibm.com/docs/containers?topic=containers-ts-delete-webhooks) from the cluster.







 Gathering data 

Follow the steps to gather the relevant worker node data.



1. Get the details of each node. Save the output details to include in your support ticket.

kubectl describe node <node-ip-address>
2. Run the [Diagnostics and Debug Tool](https://cloud.ibm.com/docs/containers?topic=containers-debug-tool) . Export the kube and network test results to a compressed file and save the file to include in your support ticket. If all workers in your cluster are affected, you can skip this step as the debug tools cannot work properly if all worker nodes are disrupted.
3. Show that there are no added mutating or validating webhooks remaining in your cluster by getting the webhook details. Save the command output to include in your support ticket. Note that the following mutating webhooks might remain and do not need to be deleted: alertmanagerconfigs.openshift, managed-storage-validation-webhooks, multus.openshift.io, performance-addon-operator, prometheusrules.openshift.io,snapshot.storage.k8s.io.

kubectl get mutatingwebhookconfigurations

kubectl get validatingwebhookconfigurations
4.
Why can't I create Block Storage for VPC snapshots? 

Infrastructure provider: VPC

  What’s happening 

You are unable to create volumesnapshots.

  Why it’s happening 

There are several reasons why you might not be able to create snapshots. To debug the issue, complete the following steps to gather the required log files before contacting support.



1.  Describe your volumesnapshot and review the status.

kubectl describe volumesnapshot VOLUMESNAPSHOT
2.  Get the logs of the ibm-vpc-block-csi-controller-0 driver and sidecar.

kubectl logs -n kube-system ibm-vpc-block-csi-controller-0 -c csi-snapshotter

kubectl logs -n kube-system ibm-vpc-block-csi-controller-0 -c iks-vpc-block-driver

kubectl logs -n kube-system ibm-vpc-block-csi-controller-0
3.  Open a [support case](https://cloud.ibm.com/docs/get-support?topic=get-support-using-avatar). In the case details, be sure to include any relevant log files, error messages, or command outputs.
Show that there are no added mutating or validating webhooks remaining in your cluster by getting the webhook details. Save the command output to include in your support ticket. Note that the following mutating webhooks might remain and do not need to be deleted: alertmanagerconfigs.openshift, managed-storage-validation-webhooks, multus.openshift.io, performance-addon-operator, prometheusrules.openshift.io,snapshot.storage.k8s.io.

kubectl get mutatingwebhookconfigurations

kubectl get validatingwebhookconfigurations
4. For classic clusters, access the KVM console for one of the affected workers. Then, gather the relevant logs and output.



1. Follow the steps to access the [KVM console](https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-access-kvm-console).
2. Gather and save the following logs. Review the logs for possible causes of the worker node disruption, such as a lack of memory or disk space, the disk entering read-only mode, and other issues.



* /var/log/boot.log
* /var/log/calico/cni/cni.log
* /var/log/crio.log
* /var/log/cron
* /var/log/messages
* /var/log/secure
* /var/log/kubelet.log



3. Run the following commands and save the output to attach to the support ticket.



* ps -aux # Dump running process
* df -H # Dump disk usage information
* vmstat # Dump memory usage information
* lshw # Dump hardware information
* last -Fxn2 shutdown reboot # determine if last restart was graceful or not
* mount | grep -i "(ro" # to rule out disk read-only issue. NOTE: tmpfs being ro is fine
* touch /this # to rule out disk read-only issue





5.
Note that the following mutating webhooks might remain and do not need to be deleted: alertmanagerconfigs.openshift, managed-storage-validation-webhooks, multus.openshift.io, performance-addon-operator, prometheusrules.openshift.io,snapshot.storage.k8s.io.

kubectl get mutatingwebhookconfigurations

kubectl get validatingwebhookconfigurations
4. For classic clusters, access the KVM console for one of the affected workers. Then, gather the relevant logs and output.



1. Follow the steps to access the [KVM console](https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-access-kvm-console).
2. Gather and save the following logs. Review the logs for possible causes of the worker node disruption, such as a lack of memory or disk space, the disk entering read-only mode, and other issues.



* /var/log/containerd.log
* /var/log/kern.log
* /var/log/kube-proxy.log
* /var/log/syslog
* /var/log/kubelet.log



3. Run the following commands and save the output to attach to the support ticket.



* ps -aux # Dump running process
* df -H # Dump disk usage information
* vmstat # Dump memory usage information
* lshw # Dump hardware information
* last -Fxn2 shutdown reboot # determine if last restart was graceful or not
* mount | grep -i "(ro" # to rule out disk read-only issue. NOTE: tmpfs being ro is fine
* touch /this # to rule out disk read-only issue





5. [Open a support ticket](https://cloud.ibm.com/unifiedsupport/cases/form) and attach all the outputs saved in the previous steps.
Check if the applications, security, or monitoring components in your cluster are overloading the cluster apiserver with requests, which may cause disruptions for your worker nodes.
3. If you recently added any components to your cluster, remove them. If you made changes to any existing components in your cluster, revert the changes. Then, check the status of your worker nodes to see if the new components or changes were causing the issue.
4. Check for changes on any cluster webhooks, which can disrupt apiserver requests or block a worker node's ability to connect with the apiserver. [Remove all webhooks](https://cloud.ibm.com/docs/containers?topic=containers-ts-delete-webhooks) that were added to the cluster after it was created.
5. Remove and regenerate any custom Docker pull secrets, which, if misconfigured, can prevent worker nodes from pulling images from Docker registries.



1. Run the ibmcloud oc delete secret -n openshift pull-secret and ibmcloud oc delete secret -n openshift-config pull-secret commands to delete the custom Docker pull secrets.

ibmcloud oc delete secret -n openshift pull-secret

ibmcloud oc delete secret -n openshift-config pull-secret
2. Wait for the cluster to regenerate the custom Docker pull secrets. Any misconfigured components are no longer present in the regenerated pull secrets.



6. Check the status of your worker nodes. If they are in a Normal state, add back any deleted components and re-create any reverted changes, one by one, until you can determine which configuration or component caused the worker node disruption.
7. If the issue is still not resolved, follow the steps to [gather your worker node data](https://cloud.ibm.com/docs/openshift?topic=openshift-ts-critical-notreadyts-critical-notready-gather) and open a support ticket.







 If worker nodes switch between normal and critical states