vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* Activity Tracker ingestions key: To receive audit logs, you must create an IBM Cloud Activity Tracker instance and an ingestion key.



There are two additional credentials you must share before your service can be deployed, the HSM client cert and the HSM client key, but these are not shared as part of deploying the UI itself. These credentials enable NTLS communications used by the Thales HSM for exchanges between the HSM and Key Protect running on your worker node. You must create and register with the HSM a TLS certificate for the worker node (client) that will connect to the HSM and provide the client certificate and key that Key Protect uses to communicate with the HSM. The exact instructions to share these credentials are communicated as part of your conversations with your service representative.





 Provisioning Key Protect 

To provision the Key Protect service, complete the following steps:



1. [Log in to your IBM Cloud account](https://cloud.ibm.com/login/).
2. Click Catalog to view the list of services that are available on IBM Cloud.
3. Search for "Key Protect" in the Search the catalog... field and click Key Protect.
4. On the Key Protect catalog page, select Satellite.
5. Note the Before you begin checklist and confirm you have completed the required steps.
6. Select the Key quota you want assigned to this location. This number represents the total number of keys which can be deployed into this location. This number can be changed later by opening a service ticket. Note that the quota can only be adjusted in groups of 100 keys. For more information, check out [Pricing for Key Protect on Satellite](https://cloud.ibm.com/docs/key-protect?topic=key-protect-pricing-plan-satellite). If you do not see the key quota section, the service plan, or the HSM fields, check with your service representative to make sure you have been added to the allowlist.
7. In the Configure your resource section:



* Give the service a Name. While not necessary, it is a best practice to choose a name relevant to the usage you plan for the service.
Why does the Ingress status show an ERRIONF error? 

Virtual Private Cloud

Classic infrastructure

Satellite

You can use the the ibmcloud oc 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 oc 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 oc ingress status-report get command, you see an error similar to the following.

The Ingress Operator is missing from the cluster (ERRIONF).

  Why it’s happening 

The Ingress Operator is included in Red Hat OpenShift by default. An underlying cluster issue is causing the Operator to not deploy successfully.

  How to fix it 

Verify that the ingress ClusterOperator resource exists in your cluster.



1.  Get the details of the ingress ClusterOperator.

oc get clusteroperator ingress

Example output.

NAME      VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
ingress   4.10.22   True        False         False      45d
2.  If the Operator exists and Progressing is True, wait 10 to 15 minutes to allow time for the Operator to finish deploying. If the operator doesn't exist, continue with the troubleshooting steps.
3.  Follow the steps to review your cluster master and worker node states.



*  [Review master health](https://cloud.ibm.com/docs/openshift?topic=openshift-debug_masterreview-master-health).
*  [Review worker node states](https://cloud.ibm.com/docs/openshift?topic=openshift-worker-node-state-reference).



4.  Refresh your cluster masters.

ibmcloud oc cluster master refresh
5.  After you refresh your cluster master, wait 10 to 15 minutes and then check the Ingress Operator status again by running the oc get clusteroperator ingress command. If the resource is still not created or is in a degraded state, contact support. 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.
VPC: Why can't I create worker nodes on dedicated hosts? 

 What’s happening 

When you try to create worker nodes on dedicated hosts, you see an error message similar to one of the following.

The dedicated hosts for the zone 'eu-de-2' are not ready.

Insufficient dedicated hosts available in zone 'us-south-3'.

Dedicated host has insufficient capacity

 Why it’s happening 

The possible causes for these issues include:



* There are no dedicated hosts in the specified zone or pool.
* There are not enough dedicated hosts available.
* There are not enough resources available on the dedicated host.



 How to fix it 

Complete the following steps to resolve the issue.



1. List your dedicated host pools and make a note of the pool ID.

ibmcloud ks dedicated pool ls
2. Lists the hosts in the pool and verify there are available hosts and that placement is enabled.

ibmcloud ks dedicated host ls --pool POOL



* If there are no dedicated hosts in the zone, [create a new dedicated host in the zone](https://cloud.ibm.com/docs/containers?topic=containers-dedicated-hostssetup-dedicated-host-cli). After creating a host, [replace the worker node to reprovision](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicli_worker_replace).
* If there are available hosts in the zone, but placement is not enabled on the dedicated host you want to use, enable host placement.

ibmcloud ks dedicated host placement enable --host HOST --pool POOL

After enabling host placement, wait to see if provisioning succeeds. If you still see provisioning errors, continue the steps to verify there are enough resources available. Or, [replace the worker node to reprovision](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicli_worker_replace).



3.
VPC: Why can't I create worker nodes on dedicated hosts? 

 What’s happening 

When you try to create worker nodes on dedicated hosts, you see an error message similar to one of the following.

The dedicated hosts for the zone 'eu-de-2' are not ready.

Insufficient dedicated hosts available in zone 'us-south-3'.

Dedicated host has insufficient capacity

 Why it’s happening 

The possible causes for these issues include:



* There are no dedicated hosts in the specified zone or pool.
* There are not enough dedicated hosts available.
* There are not enough resources available on the dedicated host.



 How to fix it 

Complete the following steps to resolve the issue.



1. List your dedicated host pools and make a note of the pool ID.

ibmcloud oc dedicated pool ls
2. Lists the hosts in the pool and verify there are available hosts and that placement is enabled.

ibmcloud oc dedicated host ls --pool POOL



* If there are no dedicated hosts in the zone, [create a new dedicated host in the zone](https://cloud.ibm.com/docs/openshift?topic=openshift-dedicated-hostssetup-dedicated-host-cli). After creating a host, [replace the worker node to reprovision](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clicli_worker_replace).
* If there are available hosts in the zone, but placement is not enabled on the dedicated host you want to use, enable host placement.

ibmcloud oc dedicated host placement enable --host HOST --pool POOL

After enabling host placement, wait to see if provisioning succeeds. If you still see provisioning errors, continue the steps to verify there are enough resources available. Or, [replace the worker node to reprovision](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clicli_worker_replace).



3.
If you import a bulk data transfer of nodes and do not also import identities, you will have to perform the separate step of associating identities with the nodes. There are a few ways to procure an identity that can operate a node. For more information about, see [Gathering certificates or credentials](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-import-nodesibp-console-import-start-here). Regardless of the process used to acquire the identity, after the bulk import has been completed you will need to click on each imported node. For peers and ordering nodes, a box on the left of the screen will say Identity not associated with (peer or ordering node), depending on the node in question. After clicking on this box, you will be able to associate the relevant identity by selecting it from your Wallet. Note that this process is distinctly different than the process for importing individual nodes, where you will be asked to associate an identity as part of the import process.

You will also need to associate an admin identity for the CA. This process is similar to the peer and ordering node process except that after you click on the imported CA you will see a separate screen asking you to associate an identity rather than a box on the left.

For cases where bulk data transfers are impractical or inadvisable, you can follow the steps below to export and import components and identities one at a time.





 Gathering certificates or credentials 

Because identities contain private keys, be careful when exporting them to ensure they are handled securely. If a private key is compromised, it can be used to perform malicious actions.

Each IBM Blockchain Platform component is deployed with the signing certificate of an administrator inside. When actions requiring the permission level of an admin are performed against the component, the signing certificate of the entity attempting the action is checked against the signing certificate inside the node. If they don't match, the action is denied. In this way, these certificates, which are also known as "keys", allow the administrator to operate their components.

If you intend to operate an imported node, you have two options:



1.
Version 4.7 is unsupported. You can review the following archive of 4.7 change logs.



 Version 4.7 change log 

View information of version changes for major, minor, and patch updates that are available for your Red Hat® OpenShift® on IBM Cloud® clusters that run version 4.7. Changes include updates to Red Hat OpenShift, Kubernetes, and IBM Cloud Provider components.



 Overview 

Unless otherwise noted in the change logs, the IBM Cloud provider version enables Red Hat OpenShift APIs and features that are at beta. Red Hat OpenShift alpha features, which are subject to change, are disabled.

Check the [Security Bulletins on IBM Cloud Status](https://cloud.ibm.com/status?selected=security) for security vulnerabilities that affect Red Hat OpenShift on IBM Cloud. You can filter the results to view only Kubernetes Service security bulletins that are relevant to Red Hat OpenShift on IBM Cloud. Change log entries that address other security vulnerabilities but don't also refer to an IBM security bulletin are for vulnerabilities that are not known to affect Red Hat OpenShift on IBM Cloud in normal usage. If you run privileged containers, run commands on the workers, or execute untrusted code, then you might be at risk.

Master patch updates are applied automatically. Worker node patch updates can be applied by reloading or updating the worker nodes. For more information about major, minor, and patch versions and preparation actions between minor versions, see [Red Hat OpenShift versions](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_versions).





 Change logs 

Review the version 4.7 change log.



 Change log for worker node fix pack 4.7.60_1594_openshift, released 02 January 2023 

The following table shows the changes that are in the worker node fix pack 4.7.60_1594_openshift. 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.7.60_1593_openshift
When the state of a resource changes, for example if a pod in a replica set goes down, the controller manager initiates correcting actions to achieve the required state.
* cloud-controller-manager: The cloud controller manager manages cloud provider-specific components such as the IBM Cloud load balancer.
* Konnectivity: Red Hat OpenShift on IBM Cloud-specific component to provide secured network connectivity for all Red Hat OpenShift master to worker node communication. The Konnectivity server works with the Konnectivity agent to securely connect the master to the worker node. This connection supports apiserver proxy requests to your pods and services, and ocexec, attach, and logs requests to the kubelet. The connection from the worker nodes to the master is automatically secured with TLS certificates.



Continuous monitoring by IBM Site Reliability Engineers (SREs)
: The Red Hat OpenShift master, including all the master components, compute, networking, and storage resources are continuously monitored by IBM Site Reliability Engineers (SREs). The SREs apply the latest security standards, detect and remediate malicious activities, and work to ensure reliability and availability of Red Hat OpenShift on IBM Cloud.

CIS Kubernetes master benchmark
: To configure Red Hat OpenShift on IBM Cloud, IBM engineers follow relevant cybersecurity practices from the Kubernetes master benchmark that is published by the [Center of Internet Security (CIS)](https://www.cisecurity.org/benchmark/kubernetes/). The cluster master and all worker nodes are deployed with images that meet the benchmark.

Secure communication via TLS
: To use Red Hat OpenShift on IBM Cloud, you must authenticate with the service by using your credentials. When you are authenticated, Red Hat OpenShift on IBM Cloud generates TLS certificates that encrypt the communication to and from the Red Hat OpenShift API server and etcd data store to ensure a secure end-to-end communication between the worker nodes and the Red Hat OpenShift master. These certificates are never shared across clusters or across Red Hat OpenShift master components.

Need to revoke existing certificates and create new certificates for your cluster?
Kubernetes version 1.19 change log 

Version 1.19 is unsupported. You can review the following archive of 1.19 change logs.



 Overview 

Unless otherwise noted in the change logs, the IBM Cloud Kubernetes Service provider version enables Kubernetes APIs and features that are at beta. Kubernetes alpha features, which are subject to change, are disabled.

For more information about major, minor, and patch versions and preparation actions between minor versions, see [Kubernetes versions](https://cloud.ibm.com/docs/containers?topic=containers-cs_versions).

Check the [Security Bulletins on IBM Cloud Status](https://cloud.ibm.com/status?component=containers-kubernetes&selected=security) for security vulnerabilities that affect IBM Cloud Kubernetes Service. You can filter the results to view only Kubernetes Cluster security bulletins that are relevant to IBM Cloud Kubernetes Service. Change log entries that address other security vulnerabilities but don't also refer to an IBM security bulletin are for vulnerabilities that are not known to affect IBM Cloud Kubernetes Service in normal usage. If you run privileged containers, run commands on the workers, or execute untrusted code, then you might be at risk.

Some change logs are for worker node fix packs, and apply only to worker nodes. You must [apply these patches](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_update) to ensure security compliance for your worker nodes. These worker node fix packs can be at a higher version than the master because some build fix packs are specific to worker nodes. Other change logs are for master fix packs, and apply only to the cluster master. Master fix packs might not be automatically applied. You can choose to [apply them manually](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_cluster_update).
Kubernetes version 1.20 change log 

Version 1.20 is unsupported. You can review the following archive of 1.20 change logs.



 Overview 

Unless otherwise noted in the change logs, the IBM Cloud Kubernetes Service provider version enables Kubernetes APIs and features that are at beta. Kubernetes alpha features, which are subject to change, are disabled.

For more information about major, minor, and patch versions and preparation actions between minor versions, see [Kubernetes versions](https://cloud.ibm.com/docs/containers?topic=containers-cs_versions).

Check the [Security Bulletins on IBM Cloud Status](https://cloud.ibm.com/status?component=containers-kubernetes&selected=security) for security vulnerabilities that affect IBM Cloud Kubernetes Service. You can filter the results to view only Kubernetes Cluster security bulletins that are relevant to IBM Cloud Kubernetes Service. Change log entries that address other security vulnerabilities but don't also refer to an IBM security bulletin are for vulnerabilities that are not known to affect IBM Cloud Kubernetes Service in normal usage. If you run privileged containers, run commands on the workers, or execute untrusted code, then you might be at risk.

Some change logs are for worker node fix packs, and apply only to worker nodes. You must [apply these patches](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_update) to ensure security compliance for your worker nodes. These worker node fix packs can be at a higher version than the master because some build fix packs are specific to worker nodes. Other change logs are for master fix packs, and apply only to the cluster master. Master fix packs might not be automatically applied. You can choose to [apply them manually](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_cluster_update).
After Console 2 has imported the Ordering Service, they will be able to create the new node.

Zoom

![Import the ordering service](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/blockchain/images/addremove_import_orderingservice.png)

Figure 4. Import the ordering service







 Create the node 

While it is not possible to ensure that the ordering service is available (that is, that a quorum of nodes are up and that a leader has been elected) without [Viewing your node logs](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-manage-consoleibp-console-manage-console-node-logs), it is a best practice to minimally ensure the likelihood that a quorum exists by verifying that the pods where the nodes have been deployed are available. This can be done by checking to make sure the relevant pods are active in the Kubernetes dashboard or by issuing kubectl get pods -n <namespace> and checking on the pods. If you do not have access to the cluster where all of the ordering nodes were created, contact the administrator of the relevant clusters. If a quorum of nodes is not available, it will not be possible to add another node to the ordering service.

To add a node, click on the tile representing the ordering service in the Nodes panel. Then click on the Ordering nodes panel and the Add another node tile. Then click Create an ordering node. This will open a series of panels similar to the process for creating an ordering service.

Zoom

![Add another node](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/blockchain/images/addremove_addnode.png)

Figure 5. Add another node

You will need to:



* Give the node a display name.
About Portworx 

Review frequently asked questions to learn more about Portworx and how Portworx provides highly available persistent storage management for your containerized apps.



 What is software-defined storage (SDS)? 

An SDS solution abstracts storage devices of various types, sizes, or from different vendors that are attached to the worker nodes in your cluster. Worker nodes with available storage on hard disks are added as a node to a storage cluster. In this cluster, the physical storage is virtualized and presented as a virtual storage pool to the user. The storage cluster is managed by the SDS software. If data must be stored on the storage cluster, the SDS software decides where to store the data for highest availability. Your virtual storage comes with a common set of capabilities and services that you can leverage without caring about the actual underlying storage architecture.





 How does Portworx work? 

As a software defined storage solution, Portworx aggregates available storage that is attached to your worker nodes and creates a unified persistent storage layer for containerized databases or other stateful apps that you want to run in the cluster. By using volume replication of each container-level volume across multiple worker nodes, Portworx ensures data persistence and data accessibility across zones.

Portworx also comes with additional features that you can use for your stateful apps, such as volume snapshots, volume encryption, isolation, and an integrated Storage Orchestrator for Kubernetes (Stork) to ensure optimal placement of volumes in the cluster. For more information, see the [Portworx documentation](https://docs.portworx.com/).





 What are the requirements to run Portworx? 

Review the requirements to [install Portworx](https://docs.portworx.com/install-portworx/prerequisites/).

For production environments, choose one of the [SDS worker node flavors](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodessds-table) for best performance.





 How can I make sure that my data is stored highly available?
About Portworx 

Review frequently asked questions to learn more about Portworx and how Portworx provides highly available persistent storage management for your containerized apps.



 What is software-defined storage (SDS)? 

An SDS solution abstracts storage devices of various types, sizes, or from different vendors that are attached to the worker nodes in your cluster. Worker nodes with available storage on hard disks are added as a node to a storage cluster. In this cluster, the physical storage is virtualized and presented as a virtual storage pool to the user. The storage cluster is managed by the SDS software. If data must be stored on the storage cluster, the SDS software decides where to store the data for highest availability. Your virtual storage comes with a common set of capabilities and services that you can leverage without caring about the actual underlying storage architecture.





 How does Portworx work? 

As a software defined storage solution, Portworx aggregates available storage that is attached to your worker nodes and creates a unified persistent storage layer for containerized databases or other stateful apps that you want to run in the cluster. By using volume replication of each container-level volume across multiple worker nodes, Portworx ensures data persistence and data accessibility across zones.

Portworx also comes with additional features that you can use for your stateful apps, such as volume snapshots, volume encryption, isolation, and an integrated Storage Orchestrator for Kubernetes (Stork) to ensure optimal placement of volumes in the cluster. For more information, see the [Portworx documentation](https://docs.portworx.com/).





 What are the requirements to run Portworx? 

Review the requirements to [install Portworx](https://docs.portworx.com/install-portworx/prerequisites/).

For production environments, choose one of the [SDS worker node flavors](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodessds-table) for best performance.





 How can I make sure that my data is stored highly available?