vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Optional: Read the relevant SAP Business Partner certified solutions documents Various SAP Open Ecosystem Partners are available from IBM Cloud, with documents on how to best use these solutions for your SAP deployment. 
 Optional: Read the relevant IBM-SAP innovation solutions documents IBM Cloud® for SAP 
 Read and follow the documents in the Pre-Requisites for SAP Workloads topic group Prepare the credentials, account structure, connectivity, software downloads, support procedures, and licensing that is needed before you begin your deployment. 
 Read and follow the Provisioning topic groups in the How to section For your specific infrastructure, follow the provisioning guidelines to set up the first servers at the sizes that are required to run your SAP systems. Planning your SAP landscape with the business is crucial to success. It is likely these documents might be read many months after the topics listed in the other steps. 
 Revisit Task 3, and follow the relevant SAP software documentation to install SAP on the infrastructure It is important to follow SAP guidance clearly, including any additional reference guidance available on SAP Notes for your chosen applications. This stage is the same as installations into servers hosted at on-premises data centers. 







 Next steps 

Review the following documentionat for your relevant configuration:



* [Fast Path of IBM Cloud Intel Bare Metal on Classic Infrastructure](https://cloud.ibm.com/docs/sap?topic=sap-fast-path-site-map-intel-bm)
* [Fast Path of IBM Cloud Intel Bare Metal Servers on VPC Infrastructure](https://cloud.ibm.com/docs/sap?topic=sap-fast-path-site-map-intel-bm-vpc)
* [Fast Path of IBM Cloud Intel Virtual Servers on VPC Infrastructure](https://cloud.ibm.com/docs/sap?topic=sap-fast-path-site-map-intel-vs-gen2)
* [Fast Path of IBM Power Virtual Servers](https://cloud.ibm.com/docs/sap?topic=sap-fast-path-site-map-power-vs)
* [Fast Path of IBM Cloud for VMware on Classic Infrastructure](https://cloud.ibm.com/docs/sap?topic=sap-fast-path-site-map-vmware-sddc)
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. If there are available hosts, and placement is enabled, review the details of your dedicated host and verify there are enough resources available to create the worker node.

ibmcloud ks dedicate host get --host HOST --pool POOL

You can also review your dedicated host resources in the [console](https://cloud.ibm.com/kubernetes/dedicated-hosts).



* If there are enough resources available, [replace the worker node that failed to reprovision](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicli_worker_replace). Note that sometimes, it is impossible to reach 100% capacity.
* If there are not enough resources on the dedicated host, reallocate your workloads to free up capacity on the host, or [create a new dedicated host in the zone](https://cloud.ibm.com/docs/containers?topic=containers-dedicated-hostssetup-dedicated-host-cli).
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 there are available hosts, and placement is enabled, review the details of your dedicated host and verify there are enough resources available to create the worker node.

ibmcloud oc dedicate host get --host HOST --pool POOL

You can also review your dedicated host resources in the [console](https://cloud.ibm.com/kubernetes/dedicated-hosts).



* If there are enough resources available, [replace the worker node that failed to reprovision](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clicli_worker_replace). Note that sometimes, it is impossible to reach 100% capacity.
* If there are not enough resources on the dedicated host, reallocate your workloads to free up capacity on the host, or [create a new dedicated host in the zone](https://cloud.ibm.com/docs/openshift?topic=openshift-dedicated-hostssetup-dedicated-host-cli).
Similarly, ensure that the Fabric level of this peer is at the [application and channel capability](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-governibp-console-govern-update-channel-available-parameters-advanced) levels of the channel.

Note that after a peer is removed from a channel, it might still show as being joined to the channel. This is because the ledger information of the channel up to the point the peer was removed is still available on the peer. Removing the peer from the channel means that the peer will receive no new channel updates, including the update that indicates that it is no longer a part of the channel. If you have any other peers joined to the channel, you can check the ledger height of those peers as compared to the peer that was removed to confirm that the removed peer is not receiving new blocks.





 Capabilities 

For a thorough look at what capabilities are how they work, check out [Channel capabilities](https://hyperledger-fabric.readthedocs.io/en/release-2.2/capabilities_concept.html).

The capability levels of a channel and the Fabric versions in the nodes on that channel must be coordinated in order for nodes and channels to function properly. That is because both nodes and capabilities work together to ensure that transactions are handled deterministically (that is, that all of the nodes process a transaction the same way). While the Fabric versions of a node are compatible with lower levels of capabilities, capabilities cannot be processed by lower levels of nodes. If a v1.4.x node attempts to read a configuration block containing a v2.x capability, the node will crash. For this reason, the console will attempt to ascertain the nodes that will be affected by a capability update and either warn you (or stop you) from updating a capability if it will cause a node to crash. More on this later.

Because of this, all of the nodes in a channel must be at least at the level of the capabilities relevant to the node. Therefore, if the organizations in your channel want to "move to v2.0", this is in practice a three step process:



1. Upgrade all of the nodes in the channel.
The tutorial has successfully been completed.







 Appendix 



 Appendix 1: Downloading the IBM MQ on Cloud files 

This section describes how to gather the various files that would have been downloaded during the guided tour, but which might have since been lost.



 Connection_info.json 

To retrieve the connection_info.txt file containing queue manager connection details:



1. Login to the IBM Cloud service instance by clicking on the relevant service shown in the table: ![Image of service instance](https://cloud.ibm.com/docs-content/v1/content/3a120b16db5fdc3e70d071af8a63ce5515c1b096/mqcloud/images/mqoc_tls_si1.png)
2. This will open the queue manger view: ![Image of queue manager details](https://cloud.ibm.com/docs-content/v1/content/3a120b16db5fdc3e70d071af8a63ce5515c1b096/mqcloud/images/mqoc_tls_qmview.png)
3. Select the queue manager to be configured to use TLS on to open the next window. Select the 'Connection information' button: ![Image of queue manager connection information](https://cloud.ibm.com/docs-content/v1/content/3a120b16db5fdc3e70d071af8a63ce5515c1b096/mqcloud/images/mqoc_tls_qmconinfo.png)
4. Download this file in the format of 'Plain text for human use'







 PlatformApiKey.json 

To create or reset your administrator api key:



1. Login to the IBM Cloud service instance by clicking on the relevant service shown in the table !
Verify that the image registry was configured by checking for a pod that begins with image-registry- in the openshift-image-registry namespace.

oc get pod -n openshift-image-registry

Example output.

NAME READY STATUS RESTARTS AGE
image-registry-63p54b8add-vkjju 1/1 Running 0 16m









 Exposing apps 

Several options exist to securely expose apps to traffic requests from the public network, from resources that are connected to your hosts' private network, or from resources in IBM Cloud. Although these options include services that are available in standard Red Hat OpenShift clusters, the implementation of these services is different in Red Hat OpenShift clusters that were created on Satellite-provided infrastructure. For example, no load balancer services are created for the Red Hat OpenShift Ingress controller in your cluster. For a list of app exposure options and steps to configure them, see [Exposing apps in Satellite clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-sat-expose-apps).





 Storing application data in persistent storage 

Unlike standard Red Hat OpenShift clusters that are created on IBM Cloud infrastructure, your Satellite clusters don't come installed with a storage driver that provides Kubernetes storage classes that are ready to use with Kubernetes persistent volumes for your apps. However, you can install your own storage driver to set up your apps to save their data in a backing storage device. Review the following common options. For more information, see [Understanding Satellite storage](https://cloud.ibm.com/docs/satellite?topic=satellite-storage-template-ov).





 Removing Satellite worker nodes or clusters 

When you remove Red Hat OpenShift clusters or worker nodes in a cluster, the hosts that provide the compute capacity for your worker nodes are not automatically deleted. Instead, the hosts remain attached to your Satellite location, but require you to reload the host to be able to reassign the hosts to other Satellite resources.



1. Back up any data that runs in the worker node or cluster that you want to save.
You change your infrastructure credentials back to the team account that created Cluster2. Now, you no longer have an orphaned cluster!



 How to fix it 

Follow the steps to review your infrastructure credentials and determine why you are seeing the credentials error.



1. Log in to the [Red Hat OpenShift clusters console](https://cloud.ibm.com/kubernetes/clusters?platformType=openshift).
2. [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster)..
3. Check which infrastructure account the region that your cluster is in currently uses to provision clusters. Replace REGION with the IBM Cloud region that the cluster is in.

ibmcloud oc credential get --region REGION

If you see a message similar to the following, then the account uses the default, linked infrastructure account.

No credentials set for resource group <resource group>.: The user credentials could not be found.
4. Check which infrastructure account was used to provision the cluster.



1. In the Worker Nodes tab, select a worker node and note its ID.
2. Open the menu ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/icons/icon_hamburger.svg) and click Classic Infrastructure.
3. From the infrastructure navigation pane, click Devices > Device List.
4. Search for the worker node ID that you previously noted.
5. If you don't find the worker node ID, the worker node is not provisioned into this infrastructure account. Switch to a different infrastructure account and try again.



5. Compare the infrastructure accounts.



* If the worker nodes are in the linked infrastructure account: Use the ibmcloud oc credential unset[command](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_credentials_unset) to resume using the default infrastructure credentials that are linked with your Pay-As-You-Go account.
The maximum number of compute nodes that are supported for the deployment value total_compute_cluster_instances is 64. The maximum number of storage nodes that are supported for the deployment value total_storage_cluster_instances is 18.
* Why is the CPU number displayed on an LSF worker node different than what is shown in the LSF Application Center GUI?

The CPU column in the LSF Application Center GUI and the ncpus column when you run the lscpu command on an LSF worker node might not show the same value.

The CPU column output that you get by running lscpu | egrep 'Model name|Socket|Thread|NUMA|CPU(s)' on an LSF worker node shows the number of CPU threads (not physical cores) on that compute instance.

If EGO_DEFINE_NCPUS=threads, then “ncpus=number of processors x number of cores x number of threads” and the CPU column value in the LSF Application Center GUI will match what you see when running lscpu on an LSF worker node.

If EGO_DEFINE_NCPUS=cores, then “ncpus=number of processors x number of cores” and the CPU column value in the LSF Application Center GUI will be half of what you see when running lscpu on an LSF worker node.

For more information, see [ncpus calculation in LSF](https://www.ibm.com/support/pages/ncpus-calculation-lsf::text=If%20EGO_DEFINE_NCPUS%3Dthreads%2C%20then%20ncpus,cores%20x%20number%20of%20threads).



IBM Spectrum Scale



* What locations are available for deploying VPC resources that make up the Spectrum Scale cluster?

Available regions and zones for deploying VPC resources and a mapping of those to city locations and data centers can be found in [Locations for resource deployment](https://cloud.ibm.com/docs/overview?topic=overview-locations). While any of the available regions can be used, resources are provisioned only in a single availability zone within the selected region.
* What permissions do I need in order to create a cluster using the offering?
If you want to allow the Sysdig agent to run on your edge nodes, see [Deploying the Sysdig agent to edge worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-edgesysdig-edge).



1. Apply a taint to the worker nodes with the dedicated=edge label. The taint prevents pods from running on the worker node and removes pods that don't have the dedicated=edge label from the worker node. The pods that are removed are redeployed to other worker nodes with capacity.

To apply a taint to all existing and future worker nodes in a worker pool:

ibmcloud ks worker-pool taint set -c <cluster_name_or_ID> --worker-pool <worker_pool_name_or_ID> --taint dedicated=edge:NoExecute

To apply a taint to individual worker nodes:

kubectl taint node -l dedicated=edge dedicated=edge:NoExecute

Now, only pods with the dedicated=edge toleration are deployed to your edge worker nodes.
2. Verify that your edge nodes are tainted.

kubectl describe nodes -l dedicated=edge | egrep "Taints|Hostname"

Example output

Taints: dedicated=edge:NoExecute
Hostname: 10.176.48.83
Taints: dedicated=edge:NoExecute
Hostname: 10.184.58.7
3. If you choose to [enable source IP preservation for an NLB 1.0 service](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancerlb_source_ip), ensure that app pods are scheduled onto the edge worker nodes by [adding edge node affinity to app pods](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancerlb_edge_nodes). App pods must be scheduled onto edge nodes to receive incoming requests.
4. Optional: You can remove a taint from the worker nodes.

To remove all taints from all worker nodes in a worker pool,
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. Import the admin identity into your Wallet before importing the node itself (the administrator of the console where the node was created will need to export the node and the admin identity).
2. If the admin of the node does not want to share their admin identity, there are two other ways to become an admin of the node:



* The administrator of the console where the node was created can create a new admin identity, associate it with the node as an additional admin identity, and export that identity to your console along with the node.
* The other option has five steps:
* The admin of the CA that was used to create the relevant identities for the peer and peer organization can register a new identity.
* Then, they can send the enroll ID and secret of that identity to the importing console, as well as exporting the CA.
* The importing console can then take the imported CA and use the enroll ID and secret to create a new identity.
* This new identity would be sent back to the console where the peer was created and added as an admin of the peer.
* Then the peer could be exported to the console where the new identity was created, allowing the new identity to operate the imported peer.





In either case, because this new admin identity would only be an admin of the peer and not the organization that owns the peer, it preserves a separation of roles between the organization admin (the sign cert listed in the MSP, which might also be the peer admin in the console where the peer was created), and the new admin of the peer which was just created and associated. This peer admin would not be an organization admin by default.
You can rerun the [reboot command](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_worker_reboot) with the --hard option to power off the worker node, or run the worker reload[command](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_worker_reload).





 Instance can't be found 

Message:

can't create IMS portal token, as no IMS account is linked to the selected BSS account

Provided user not found or active

User account is currently cancel_pending.

The worker node instance '<ID>' can't be found. Review '<provider>' infrastructure user permissions.

The worker node instance can't be found. Review '<provider>' infrastructure user permissions.

The worker node instance can't be identified. Review '<provider>' infrastructure user permissions.

Description and resolution:

The owner of the API key that is used to access the IBM Cloud infrastructure portfolio does not have the required permissions to perform the action, or might be pending deletion.

As the user, follow these steps:



1. If you have access to multiple accounts, make sure that you are logged in to the account where you want to work with Red Hat OpenShift on IBM Cloud.
2. Run ibmcloud oc api-key info --cluster <cluster_name_or_ID> to view the current API key owner that is used to access the IBM Cloud infrastructure portfolio.
3. Run ibmcloud account list to view the owner of the IBM Cloud account that you currently use.
4. Contact the owner of the IBM Cloud account and report that the API key owner has insufficient permissions in IBM Cloud infrastructure or might be pending to be deleted.



As the account owner, follow these steps:



1.
[Reload your classic worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_reload) or [replace your VPC worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicli_worker_replace) to pick up the certificates that are signed by the new CA.
8. Rotate the old certificates with the new certificates. The old CA certificates in your cluster are removed.

ibmcloud ks cluster ca rotate -c CLUSTER
9. Check the status of the CA certificate rotation.

ibmcloud ks cluster ca status -c CLUSTER

Example output

Status: CA certificate rotation complete.
Action Started: 2020-08-30T16:37:56+0000
Action Completed: 2020-08-30T16:41:13+0000









 Worker node 

Worker nodes carry the deployments and services that make up your app. When you host workloads in the public cloud, you want to ensure that your app is protected from being accessed, changed, or monitored by an unauthorized user or software.



 Who owns the worker node and am I responsible to secure it? 

The ownership of a worker node depends on the type of cluster that you create and the infrastructure provider that you choose.



* Classic clusters: Worker nodes are provisioned in to your IBM Cloud account. The worker nodes are dedicated to you and you are responsible to request timely updates to the worker nodes to ensure that the worker node OS and IBM Cloud Kubernetes Service components apply the latest security updates and patches.
* VPC clusters: Worker nodes are provisioned in to an IBM Cloud account that is owned by IBM to enable monitoring of malicious activities and apply security updates. You can't access your worker nodes by using the VPC dashboard. However, you can manage your worker nodes by using the IBM Cloud Kubernetes Service console, CLI, or API. The virtual machines that make up your worker nodes are dedicated to you and you are responsible to request timely updates so that your worker node OS and IBM Cloud Kubernetes Service components apply the latest security updates and patches.
When your app must be rescheduled, Portworx moves your app to a worker node where one of your volume replicas resides to ensure local-disk access speed and best performance for your stateful app. Running hyper-converged offers the best performance for your pods, but requires storage to be available on all worker nodes in your cluster.

You can also choose to use only a subset of worker nodes for your Portworx storage layer. For example, you might have a worker pool with SDS worker nodes that come with local raw block storage, and another worker pool with virtual worker nodes that don't come with local storage. When you install Portworx, a Portworx pod is scheduled onto every worker node in your cluster as part of a DaemonSet. Because your SDS worker nodes have local storage, these worker nodes are into the Portworx storage layer only. Your virtual worker nodes are not included as a storage node because of the missing local storage. However, when you deploy an app pod to your virtual worker node, this pod can still access data that is physically stored on an SDS worker node by using the Portworx DaemonSet pod. This setup is referred to as storage-heavy and offers slightly slower performance than the hyper-converged setup because the virtual worker node must talk to the SDS worker node over the private network to access the data.

Red Hat OpenShift on IBM Cloud does not support the [Portworx experimental InitializerConfiguration admission controller](https://docs.portworx.com/portworx-install-with-kubernetes/storage-operations/hyperconvergence/initializer-experimental-feature-in-stork-v1-1).





 Can I install Portworx in a private cluster? 

Yes. If you want to install Portworx in a private cluster, your IBM Cloud account must be set up with [Virtual Routing and Forwarding (VRF)](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointvrf) and access to private cloud service endpoints for IBM Cloud services.