vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Review the log file to ensure that no errors occurred during the provisioning, modification, or deletion process.







 Deploying SAP NetWeaver 7.x and SAP HANA by using Terraform 

Use these steps to configure the IBM Cloud Provider plug-in and use Terraform to create VPC resources for SAP. The scripts can take 2 hours to complete.



1. Log in to the Bastion Deployment Server by using ssh.
2. Clone the terraform and ansible folders and README files.

ForJava: Clone the files from https://github.com/IBM-Cloud/sap-netweaver-java-hana and change to the sap-netweaver-java-hana/cli/terraform folder.

$ git clone https://github.com/IBM-Cloud/sap-netweaver-java-hana.git
$ cd sap-netweaver-java-hana/cli/terraform

For ABAP: Clone the files from [https://github.com/IBM-Cloud/sap-netweaver-abap-hana](https://github.com/IBM-Cloud/sap-netweaver-abap-hana) and change to the sap-netweaver-abap-hana/cli/terraform folder.

$ git clone https://github.com/IBM-Cloud/sap-netweaver-abap-hana.git
$ cd sap-netweaver-abap-hana/cli/terraform
3. Define your existing VPC variables. Modify the input.auto.tfvars file to specify your zone, VPC component names, profile, and image. The file is preset with the minimal recommended disk sizes. You need your 40-digit SSH key ID for this file. The second SSH key is optional. For more options for profile, see [Instance Profiles](https://cloud.ibm.com/docs/vpc?topic=vpc-profiles).
[Image showing default queue manager certificate](https://cloud.ibm.com/docs-content/v1/content/3a120b16db5fdc3e70d071af8a63ce5515c1b096/mqcloud/images/mqoc_cert_icons.png)

The default certificate has a 90 day expiration period. When nearing expiry the following process is invoked by the service:



* Approximately 30 days before expiration a new certificate is added to the queue manager key store



* Queue managers that have not been configured to enable TLS will use the new certificate by default
* Queue managers that are configured to use TLS will continue to use the old certificate, the new certificate is made available for use
* The MQ Console and REST APIs for existing queue managers continue to the use the old certificate
* The MQ Console and REST APIs for new queue managers use the new certificate



* Approximately 14 days before expiration the new certificate becomes the default



* Queue managers that are configured to use TLS or AMS will have the default certificate replaced with the new certificate (MQ clients will be disconnected for a short time, while the security configuration is refreshed)
* The MQ Console and REST APIs use the new certificate
* The old certificate is removed from the queue manager key store





Queue managers that have been configured to use a customer generated certificate remain unaffected by the above process. Customer generated certificate expiry is the responsibility of the queue manager administrator

Certificates originally had an expiration period of 1 year. This has been reduced to 90 days





 Handling certificate expiry 

The IBM MQ on Cloud service will provide notifications in the service console user interface when IBM provided certificates near expiry. If you wish to configure notification of certificate expiry via other channels such as Slack or PagerDuty then please use the IBM Cloud [Certificate Manager](https://cloud.ibm.com/docs/services/certificate-manager?topic=certificate-manager-about-certificate-manager) service.

Within 30 and 14 days of expiry increasingly severe warnings are displayed in the queue manager list view and on the queue manager details pages.
For more information, see [IBM Cloud CLI for VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-set-up-environment).



Table 1. SSH key actions

 Action Command What happens next 

 Create SSH key. [ibmcloud is key-create](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-reference&interface=clikey-create) After you create an SSH key, it is added to the list of keys. 
 View key details. [ibmcloud is key](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-reference&interface=clikey-view) You can view the name of the key and the ID of the key. 
 List keys. [ibmcloud is keys](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-reference&interface=clikeys-list) You can view all of your existing SSH keys. 
 Update key. [ibmcloud is key-update](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-reference&interface=clikey-update) After you update an existing key, the key is renamed immediately. 
 Delete key. [ibmcloud is key-delete](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-reference&interface=clikey-delete) After you remove an SSH key, it can no longer be used when you provision an instance or when you perform an OS reload on an existing instance. However, the key is still available on any instances that you previously provisioned with it, and you can use it to log in. 







 Managing SSH keys by using the API 

You can also manage your SSH keys by using the API.
"resource_plan_id": "<service-id>"
"point_in_time_recovery_time":"<TIMESTAMP>",
"point_in_time_recovery_deployment_id":"<DEPLOYMENT_ID>"
}'

The point-in-time-recovery timestamp must be formatted as follows: %Y-%m-%dT%H:%M:%SZ.

The parameters name, target, resource_group, and resource_plan_id are all required. The target is the region where you want the new deployment to be located, which can be a different region from the source deployment. Cross region restores are supported, except for restoring a eu-de backup to another region.

For PITR, use the point_in_time_recovery_time and point_in_time_recovery_deployment_id parameters. The point_in_time_recovery_deployment_id is the source deployment's ID and point_in_time_recovery_time is the timestamp in Coordinated Universal Time you want to restore to. To restore to the latest available point-in-time use "point_in_time_recovery_time":" ".

If you need to adjust resources or use a Key Protect key, add the optional parameters key_protect_key, members_disk_allocation_mb, members_memory_allocation_mb, and/or members_cpu_allocation_count, and their values to the body of the request.





 Restoring a backup with Terraform 

Before restoring, ensure that your point_in_time_recovery_time is no older than one week. If the timestamp is any older than 7 days, down to the second, validation fails.
Usage: slcli file volume-cancel [OPTIONS] VOLUME_ID

Options:
--reason TEXT An optional reason for cancellation.
--immediate Cancels the file storage volume immediately instead of on the
billing anniversary.
-h, --help Show this message and exit.

When the volume is canceled, the request is followed by a 24-hour reclaim wait period. You can still see the volume in the console during those 24 hours. Billing for the volume stops immediately. When the reclaim-period expires, the data is destroyed and the volume is removed from the console, too. For more information, see the [FAQs](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-file-storage-faqs).

Active replicas and dependent duplicates can block reclamation of the Storage volume. Make sure that the volume is no longer mounted, host authorizations are revoked, replication is canceled, and no dependent duplicates exist before you attempt to delete the original volume.
You can point your domain only to a CDN CNAME (IBM CNAME or the Akamai CNAME). This way, you can guarantee that your domain is globally distributed to the closest and most efficient edge server for your clients.

The IP addresses of an Akamai edge server are changed dynamically; therefore, setting a fixed Akamai IP address for your domain might cause your traffic to fail.





 Can I update the IBM CNAME or Akamai CNAME? 

No, you can't update the IBM CNAME or Akamai CNAME. You can only define the prefix of the IBM CNAME when you're creating the CDN. The Akamai CNAME is generated automatically by Akamai and you do not have to define or edit it.





 When should I use the Akamai CNAME instead of IBM CNAME? 

Akamai CNAME provides a shorter DNS lookup time for your domain. The Akamai CNAME improves the performance of your website by shortening the DNS resolution time.

You can only point your domain to the Akamai CNAME when the CDN mapping status is in RUNNING state.





 What happens if a domain is still pointing to Akamai CNAME when the CDN is stopped? 

When the CDN is stopped, a Deny_All rule is added for the domain on the Akamai side. Even if the domain can still be resolved to Akamai by pointing to Akamai CNAME, the traffic for the domain is denied, and the response is similar to the following:

HTTP/2 403
server: AkamaiGHost
mime-version: 1.0
content-type: text/html
content-length: 269
expires: Tue, 15 Sep 2020 07:54:31 GMT
date: Tue, 15 Sep 2020 07:54:31 GMT

<HTML><HEAD>
<TITLE>Access Denied</TITLE>
</HEAD><BODY>
<H1>Access Denied</H1>

You do not have permission to access "http://xxxx;" on this server.<P>
Queue manager certificate administration 

When using IBM MQ on Cloud it is important to protect data that flows through your queue managers. Public certificates and private keys can be used to encrypt data in transit and at rest using transport layer security (TLS) and Advanced Message Security (AMS). IBM MQ on Cloud provides a default certificate and private key pair for your queue manager on creation. The certificate and private key pair can be used to authenticate the queue manager to connecting MQ clients and encrypt/decrypt data. The IBM MQ on Cloud service provides the ability for administrators to use their own customer generated certificates and manage their use within the queue manager. This document covers how the provided certificates are managed by the service, steps administrators will need to follow to manage expiring certificates and how to import your own customer generated certificates.



 IBM certificate management policy 

When a queue manager is created a default certificate chain is added to the queue manager's key store and trust store. The key store contains the certificate used by the queue manager and the trust store contains the intermediate and root CA certificates used to sign the queue manager certificate. The default certificate is configured for use on the queue manger, the MQ Console and REST APIs. Only the queue manager certificate can be replaced.

Certificates can be viewed in the service by selecting a queue manager and clicking the Key store tab. The image below shows a certificate in the key store, the icons (which are greyed out when not in use) from left to right represent:



* Queue manager default certificate (used when no explicit certificate is chosen in configuration)
* Used in TLS channel configuration
* Used in AMS channel configuration
* Used by MQ Console and REST APIs



![Image showing default queue manager certificate](https://cloud.ibm.com/docs-content/v1/content/3a120b16db5fdc3e70d071af8a63ce5515c1b096/mqcloud/images/mqoc_cert_icons.png)

The default certificate has a 90 day expiration period. When nearing expiry the following process is invoked by the service:
Scroll to confirm that Deployment and Create a route to the application are selected, and then click Create.
10. Wait a few minutes for the pods to deploy. To check the status of the pods, from the Topology pane, click your nodejs app and review its sidebar. You must see that the nodejs build is complete, and that the nodejs pod is in a Running state to continue.
11. When the deployment is complete, click the route location URL, which has a format similar to the following.

http://nodejs-<project>.<cluster_name>-<hash>.<region>.containers.appdomain.cloud

A new tab in your browser opens with a message similar to the following.

Welcome to your Node.js application on OpenShift
12. Optional: To clean up the resources that you created, select Administrator from the perspective switcher, navigate to Home > Projects, click your project's action menu, and click Delete Project.







 What's next? 



What's next after completing the Red Hat OpenShift on IBM Cloud getting started?

 Suggestion What you learn about Red Hat OpenShift 

 [Red Hat OpenShift on IBM Cloud classic cluster tutorial](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_tutorial) or [Red Hat OpenShift on IBM Cloud VPC cluster tutorial](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc_rh_tutorial) <br><br> * Set up your IBM Cloud and Red Hat OpenShift CLI.<br> * Deploy an app that uses an IBM Cloud service.<br><br><br> 
 [Learning path for administrators](https://cloud.ibm.com/docs/openshift?topic=openshift-learning-path-admin) See an overview of all the options in Red Hat OpenShift on IBM Cloud for administrators.
Why can't I use the Red Hat annotations to restrict access to the Red Hat OpenShift Console? 

Virtual Private Cloud

Classic infrastructure

  What’s happening 

When you use the Red Hat ip_whitelist allowlist annotation to allow only certain source IP addresses to access the Red Hat OpenShift Console, it does not work as expected.

  Why it’s happening 

By default, the source IP address is not preserved from the client (console web browser) through the load balancer and to the router pod. Because the source IP address isn't available when the filtering is done in the router pod, you can't use the ip_whitelist annotation to allow certain IP addresses to access the console.

  How to fix it 

Do not use the Red Hat ip_whitelist annotation to restrict Red Hat OpenShift Console access to specific IP address or IP address ranges. Instead, use Context Based Restrictions (CBR) for this purpose.

For more information, see [Allowing Red Hat OpenShift on IBM Cloud to access other IBM Cloud resources by using CBR](https://cloud.ibm.com/docs/openshift?topic=openshift-cbr&interface=uicbr-integrations).
Or, you can create a Kubernetes LoadBalancer service for your apps, and a VPC load balancer is automatically generated. VPC load balancers are multizone and route requests for your app through the private node ports that are automatically opened on your worker nodes. If the public and private cloud service endpoints are enabled, the routers and VPC load balancers are created as public by default. If only the private cloud service endpoint is enabled, the routers and VPC load balancers are created as private by default. For more information, see [Public](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_network_planningpattern_public_vpc) or [Private app networking for VPC clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_network_planningprivate_vpc). Calico is used as the cluster networking policy fabric.

Storage
: You can set up IBM Cloud Object Storage and Cloud Databases only.







 Overview of personal and sensitive data storage and removal options 

Review what information is stored with IBM when you use Red Hat OpenShift on IBM Cloud, how this data is stored and encrypted, and how you can permanently remove this information.



 What information is stored with IBM when using Red Hat OpenShift on IBM Cloud? 

For each cluster that you create with Red Hat OpenShift on IBM Cloud, IBM stores the information that is described in the following table:



Table 1. Information that is stored with IBM

 Information type Data 

 Personal information The email address of the IBM Cloud account that created the cluster. 
 Sensitive information <br><br> * The TLS certificate and secret that is used for the assigned Ingress subdomain.<br> * The certificate authority that is used for the TLS certificate.<br> * The certificate authority, private keys, and TLS certificates for the Red Hat OpenShift master components, including the Red Hat OpenShift API server, etcd data store, and VPN.<br> * A customer root key in IBM Key Protect for each IBM Cloud account that is used to encrypt personal and sensitive information.<br><br><br>
SAP Data Hub 2.x 

SAP Data Hub 2.x is a distributed data orchestration and management software for creation of data-driven business processes. SAP Data Hub 2.x is replaced by SAP Data Intelligence 3.x.

Installation of SAP Data Hub 2.x is available for Red Hat OpenShift on IBM Cloud. The OpenShift platform is managed by IBM Cloud, but you have full control of the size and number of worker nodes available for deployment worldwide.

This documentation appends to Red Hat's article [SAP Data Hub 2 on OpenShift Container Platform 3](https://access.redhat.com/articles/3630111) (referred as acronym RHA)

Any considerations or guidance that is provided by IBM Cloud® for SAP, does not replace implementation documentation for Red Hat OpenShift and SAP Data Hub.

Many of the implementation steps are in the [SAP Data Hub 2 on OpenShift Container Platform 3 article (RHA)](https://access.redhat.com/articles/3630111). The How To guidance provides the additional IBM Cloud-specific steps:



* [Planning your deployment](https://cloud.ibm.com/docs/sap?topic=sap-rhos-planning-items)
* [Deploying your OpenShift cluster and jump host](https://cloud.ibm.com/docs/sap?topic=sap-rhos-set-up-cluster)
* [Preparation and Installation of SAP Data Hub](https://cloud.ibm.com/docs/sap?topic=sap-rhos-datahub)





 Before you begin with SAP Data Hub 2.x and Red Hat OpenShift on IBM Cloud 

To get started, you need to be familiar with IBM Cloud, OpenShift, and SAP Data Hub. Depending on your current level of knowledge, read some or all of the following documentation.



* Containers and Kubernetes...



* [What are Containers?](https://www.ibm.com/cloud/learn/containers)
* [What is Kubernetes?](https://www.ibm.com/cloud/learn/kubernetes)
By default, Kubernetes requires every request to go through several stages before access to the API server is granted.

Authentication
: Validates the identity of a registered user or service account.

Authorization
: Limits the permissions of authenticated users and service accounts to ensure that they can access and operate only the cluster components that you want them to.

Admission control
: Validates or mutates requests before they are processed by the Red Hat OpenShift API server. Many Kubernetes features require admission controllers to properly function.





 What does Red Hat OpenShift on IBM Cloud do to secure my API server and etcd data store? 

The following image shows the default cluster security settings that address authentication, authorization, admission control, and secure connectivity between the Kubernetes master and worker nodes.

Zoom

![Describes the security stages when you access the Kubernetes API server.](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/openshift/images/oc_security_apiserver_access.png)

Figure 1. Security stages when accessing the Kubernetes API server

Review the following security features for Red Hat OpenShift API server and etcd.

Fully managed and dedicated Red Hat OpenShift master
: Every cluster in Red Hat OpenShift on IBM Cloud is controlled by a dedicated Red Hat OpenShift master that is managed by IBM in an IBM-owned IBM Cloud account. The Red Hat OpenShift master is set up with the following dedicated components that are not shared with other IBM customers.



* etcd data store: Stores all Kubernetes resources of a cluster, such as Services, Deployments, and Pods. Kubernetes ConfigMaps and Secrets are app data that is stored as key value pairs so that they can be used by an app that runs in a pod. Data in etcd is stored on the local disk of the Red Hat OpenShift master and is backed up to IBM Cloud Object Storage. Data is encrypted during transit to IBM Cloud Object Storage and at rest.
Why does the Ingress status show an ESSSMG error? 

Virtual Private Cloud

Classic infrastructure

Satellite

  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 example.

Could not the secret group (ESSSMG).

  Why it’s happening 

Red Hat OpenShift on IBM Cloud is unable to access the secret group that was registered with the cluster to upload the default Ingress certificates.

  How to fix it 

Review your service-to-service authorization policies and verify that communication between Red Hat OpenShift on IBM Cloud and Secrets Manager is enabled.



1.  [Follow the steps to ensure there is a service-to-service authorization policy](https://cloud.ibm.com/docs/openshift?topic=openshift-secrets-mgrsecrets-mgr_setup_s2s) configured to enable communication between Red Hat OpenShift on IBM Cloud and Secrets Manager.
2.  If the policy exists, verify that the secret group registered with the cluster exists in the instance.



*  To view the instance registration details for your cluster run the ibmcloud oc ingress instance ls command.
*  To view and modify the secret groups available in your instance, see [Organizing your secrets](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-secret-groups).
*  To update the secret group for your cluster, run the ibmcloud oc ingress instance default set command and specify the --secret-group option.



3.  If the issue persists, 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.
Deploying your OpenShift cluster and jump host 

This topic takes you through the steps of creating the Red Hat® OpenShift® on IBM Cloud® cluster and your jump host.



 Before you begin 

When you create the Red Hat OpenShift on IBM Cloud cluster, it is important that the flavor meets SAP's sizing recommendations and your expected workload characeterisitcs, as well as the expected data volumes. The flavor used in this provisioning scenario is appropriate for a test environment. Use this scenario to create your own test environment or adapt the scenario for your needs. Refer to the most recent SAP documentation when creating your cluster. The following implementation scenario is based on [Minimum Sizing for SAP Data Hub 2.7](https://help.sap.com/viewer/1f833eab23244ef2ad66fe982dd14873/2.7.latest/en-US/d771891d749d425ba92603ec9b0084a8.html). When planning to setup and deploy a production cluster you must consult [Sizing Guide for SAP Data Hub 2.7](https://help.sap.com/viewer/1f833eab23244ef2ad66fe982dd14873/2.7.latest/en-US/d771891d749d425ba92603ec9b0084a8.html).

Please check that your IBM Cloud account is set up to create clusters. For more information and the steps to set up your account, see [Prepare to create clusters at the account level](https://cloud.ibm.com/docs/openshift?topic=openshift-clusterscluster_prepare).





 Provisioning your OpenShift cluster 

Use the following steps to create your Red Hat OpenShift on IBM Cloud cluster. The values used in this scenario are suggestions for a test environment. Select the optional values that will fit your needs.

The Information button provides field-specific information on how to use a field.



1.
What if my OpenShift Data Foundation issue is still unresolved? 

If your ODF issue is still unresolved or is not addressed in the troubleshooting steps, contact ODF support by raising a case in the Red Hat customer portal.



1.  [Access the Red Hat Customer Portal](https://access.redhat.com) and sign in with your support credentials.
2.  Find the Troubleshoot a product issue section and select Red Hat OpenShift Data Foundation.
3.  Select the version of your ODF instance.
4.  Click Continue.
5.  Use the Red Hat must-gather tool to collect data about your cluster in a compressed file. For more information, see [Gathering data about your cluster](https://docs.openshift.com/container-platform/4.6/support/gathering-cluster-data.htmlgathering-data-specific-features_gathering-cluster-data).

oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:latest --dest-dir=ocs_mustgather
6.  Follow the prompts to describe the issue you have. Attach the file with the must-gather data you collected earlier.
7.  Click Open a case to submit your issue.