vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Install Docker Engine - Community for Ubuntu following the instructions from [https://docs.docker.com/install/linux/docker-ce/ubuntu/](https://docs.docker.com/install/linux/docker-ce/ubuntu/).
3. Verify the installation with:

docker --version
sudo docker run hello-world

To run Docker under your own user instead of root, perfom the [post install](https://docs.docker.com/install/linux/linux-postinstall/) steps.







 kubectl 



1. Download kubectl from

[https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux](https://kubernetes.io/docs/tasks/tools/install-kubectl/install-kubectl-on-linux).
2. Make the kubectl binary executable.

chmod +x ./kubectl
3. Move the binary to your PATH.

sudo mv ./kubectl /usr/local/bin/kubectl
4. Verify the installation with:

kubectl version --client=true







 oc 



1. Download the latest 4.x OpenShift CLI (oc) from [https://mirror.openshift.com/pub/openshift-v4/clients/ocp/stable/](https://mirror.openshift.com/pub/openshift-v4/clients/ocp/stable/).
2. Extract openshift-client-linux.tar.gz:

tar zxvf openshift-client-linux.tar.gz oc
3. Move the oc binary to your PATH.

sudo mv ./oc /usr/local/bin/oc
4. Verify the installation with:
You don't need to resize or rebalance the worker pool manually.





 Following scalable deployment practices 

Make the most out of the cluster autoscaler by using the following strategies for your worker node and workload deployment strategies. For more information, see the [Kubernetes Cluster Autoscaler FAQs](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md).

[Try out the cluster autoscaler](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-helm) with a few test workloads to get a good feel for how [scale-up and scale-down work](https://cloud.ibm.com/docs/containers?topic=containers-caca_about), what [custom values](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-helmca_chart_values) you might want to configure, and any other aspects that you might want, like [overprovisioning](https://cloud.ibm.com/docs/containers?topic=containers-cluster-scaling-deploy-appsca_scaleup) worker nodes or [limiting apps](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-deploy-apps). Then, clean up your test environment and plan to include these custom values and additional settings with a fresh installation of the cluster autoscaler.



 Can I autoscale multiple worker pools at once? 

Yes, after you install the cluster autoscaler, you can choose which worker pools within the cluster to autoscale [in the ConfigMap](https://cloud.ibm.com/docs/containers?topic=containers-cluster-scaling-enable). You can run only one autoscaler per cluster. Create and enable autoscaling on worker pools other than the default worker pool, because the default worker pool has system components that can prevent automatically scaling down.





 How can I make sure that the cluster autoscaler responds to what resources my app needs?
* Install SAP HANA on RHEL:



* [SAP Note 2772999 - Red Hat Enterprise Linux 8.x: Installation and Configuration](https://me.sap.com/notes/2772999)
* [SAP Note 2777782 - SAP HANA DB: Recommended OS Settings for RHEL 8](https://me.sap.com/notes/2777782)



* SAP HANA Server Installation:



* [SAP HANA Server Installation and Update Guide](https://help.sap.com/docs/SAP_HANA_PLATFORM/2c1988d620e04368aa4103bf26f17727/7eb0167eb35e4e2885415205b8383584.html?locale=en-US)



* SAP HANA System Replication:



* [SAP HANA System Replication Guide](https://help.sap.com/docs/SAP_HANA_PLATFORM/4e9b18c116aa42fc84c7dbfd02111aba/afac7100bc6d47729ae8eae32da5fdec.html?locale=en-US)



* Configure SAP HANA System Replication:



* [Automating SAP HANA Scale-Up System Replication by using the RHEL HA Add-On - 2. SAP HANA System Replication](https://access.redhat.com/articles/3004101sap-hana-system-replication)





* A valid RHEL for SAP Applications or RHEL for SAP Solutions subscription is required to enable the repositories that you need to install SAP HANA and the resource agents for HA configurations.
* [What you need to know about this change](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_notices_vperegistry_notices_vpe_know)
* [How you benefit from this change](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_notices_vperegistry_notices_vpe_benefit)
* [Understanding if you are impacted by this change](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_notices_vperegistry_notices_vpe_impact)
* [What actions you must take](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_notices_vperegistry_notices_vpe_actions)



[Changes to private IP addresses from 15 December 2022](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_notices_ip_addressregistry_notices_ip_address)



* [What you need to know about this change](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_notices_ip_addressregistry_notices_ip_address_know)
* [What actions you need to take](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_notices_ip_addressregistry_notices_ip_address_actions)



[Container Registry CLI stops returning security status results in lists by default from version 1.0.0](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_notices_listsregistry_notices_lists)



* [Action required now](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_notices_listsregistry_notices_lists_action)



[Container Registry private IP addresses changed on 5 July 2022](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_notices_iam_private_networkregistry_notices_iam_private_network)
Learn about the vSphere Recovery Agent 

The vSphere Recovery Agent (VRA) is a Windows® application, which can back up and restore VMDKs up to 10 TB. You can install the vSphere Recovery Agent on a physical or virtual machine that has local network access to the vCenter that you want to protect. For best performance, install the VRA on a server that is in the same subnet as the vCenter. To distribute the workload, up to five VRAs can protect VMs that are attached to a single vCenter.

In a vSAN stretched cluster, each VM has a preferred site. Ideally, one local VRA is installed in each site that backs up preferred VMs of that site. If a VM is moved to a different site (because of maintenance or failures), backup performance can be degraded but remain acceptable.



 Installing the plug-in 

Ensure that power management is disabled on the server where you install the VRA.



1. Download the installation kit from http://downloads.service.softlayer.com/evault/. Then, double-click the installation kit.
2. On the confirmation message, click YES.
3. On the welcome page, click Next.
4. On the End-User-License Agreement page, read the license agreement. If you agree to the terms, click the checkbox, and then click Next.
5. On the Destination Folder page, take one of the following actions.



* To install the VRA in the default location, click Next.
* To install the VRA in another location, click Change. In the Change destination folder dialog box, browse to the new installation folder, or type it in the Folder name box. Click OK. On the Destination Folder page, click Next.



6. On the Register Agent with Portal Page, specify the following information.



* In the Network address field, type cloudbackupregister.service.softlayer.com.
* In the Port field, type 8086.
* In username field, type the IBM Cloud Backup for Classic username for managing the VRA.
* UI
* Terraform







 Deploying SAP NetWeaver 7.x and ASE SYB on an existing IBM Cloud VPC (Terraform and Ansible) 

Terraform on IBM Cloud® enables predictable and consistent provisioning of IBM Cloud Virtual Private Cloud (VPC) infrastructure resources so that you can rapidly build complex, cloud environments. IBM Cloud VPC infrastructure consists of SAP certified hardware that uses Intel Xeon CPUs and additional Intel technologies.

You can use Terraform scripts to create either:



* A single-tier VPC and create the SAP and ASE SYB infrastructure on the VPC within same host (VSI)
* A 3-tier (distributed) system and create the SAP and ASE SYB infrastructure on the separate hosts (VSIs).



The Terraform scripts use the VPC information that you provide and then call the Ansible playbook to create the SAP architecture on the specified VPC.



 What is created 

The scripts use the information that you provide for an existing VPC and deploy NW7.X with ASE SYB. For more information about this architecture, see [SAP NetWeaver 7.x on UNIX with ASE SYB on IBM Cloud VPC](https://cloud.ibm.com/docs/sap?topic=sap-sap-refarch-nw-sybase). You specify the information for the VPC to use in the input.auto.tfvars file.

The scripts call the Ansible Playbook to install the SAP architecture.





 Schematics deployment 

When you run the scripts with the Schematics interface, you:



* Enter the URL for the GitHub repository for the Schematics Terraform files
* Modify the parameters in the Schematics interface. They are the same parameters as the input.auto.tfvars file that you use with the cli.







 Terraform deployment 

The configuration and script files are provided on GitHub. Each supported interface for the SAP solution installation has its own folder in the GitHub repository:
For more information, see [Assigning users access to projects](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-access-project).







 Upload SAP software installation packages 

Upload SAP software installation packages and SAP maintenance planer XML files to an existing Object Storage bucket.

To configure access to these software packages from a running virtual server instance, you need following information:



* Object Storage endpoint
* Object Storage bucket name
* Object Storage HMAC access key
* Object Storage HMAC secret access key



For more information about configuring API access in Object Storage, see the [Getting started with IBM Cloud Object Storage](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-getting-started-cloud-object-storage) and [Service credentials](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-service-credentia) documentation.





 Define hostnames 

Define hostnames for all the SAP services that you will deploy in the landscape. You will perform mapping of the hostnames to the IP addresses later after resources become provisioned. The domain name must be the same for all hostnames belonging to one SAP system.





 Determine size parameters 

Determine the size parameters for each SAP workload that you plan to deploy. The most important parameters are memory size (especially for SAP HANA) and the number of SAPs. Most of the other configurations can be derived from these two key metrics.

For more information, see [Sizing process for SAP Systems](https://cloud.ibm.com/docs/sap?topic=sap-sizing) and see [SAP Sizing](https://service.sap.com/quicksizer).

For deployment of each SAP system, you must be aware about how many SAP NetWeaver instances you plan to deploy. Decide if you plan to use a separate PowerVS instance for hosting SAP shared files.

For deployment of each SAP NetWeaver PowerVS instance, you must be aware of following sizing parameters:



* Memory size
* Number of CPUs
Removing a disk For more information about removing a disk from a VM, see [Add an existing hard disk to a virtual machine](https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.vm_admin.doc/GUID-BDDECFBC-2FD5-4E4A-ABC7-AD274F4F40B4.html?hWord=N4IghgNiBcIEoFMC2B7AbggBGTAJMATgCaYAiAlgM4DWIAvkA). 
 VM Tools For more information about the process for updating VM Tools, see [Creating baselines and attaching to inventory objects](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vum-baselinesvum-baselines). 
 Determine the virtual disk format and convert a virtual disk from the thin provision format to a thick provision format For more information about converting a VM disk from the thin provision format to the thick provision format, see [Determine the virtual disk format and convert a virtual disk from the thin provision format to a thick provision format](https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.vm_admin.doc/GUID-E8F50BEC-F575-4AB1-BC77-D9A13CDBDCF7.html). 
 AD/DNS server OS Updates The Microsoft® Active Directory™ (AD) / Domain Name Server (DNS) is automatically set up to download updates only. For more information, see [Windows automatic installation of updates](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-trbl_limitationstrbl_limitations-windows-update). 







 vCenter procedures 



Table 3. vCenter procedures

 Title Description
Modify the following values specific to Discovery you previously created on IBM Cloud®:



* environment_id - Your Discovery environment ID.
* collection_id - Your Discovery collection ID.
* configuration_id - Your Discovery configuration ID.
* configuration - The full path location of this discovery_service.conf file, for example, /home/config/discovery/discovery_service.conf.
* username - Username credential for your Discovery instance.
* apikey - Credential for your Discovery instance.



There are other optional settings in this file that might be set as appropriate to your environment. See [Configuring Service Options](https://cloud.ibm.com/docs/discovery?topic=discovery-configuring-the-data-crawlerconfiguring-service-options) for detailed information about setting these values.
3. After modifying these files, you are ready to crawl your data. Proceed to [Crawling your data repository](https://cloud.ibm.com/docs/discovery?topic=discovery-crawling-your-data-repository) to continue.





 Configuring crawl options 

The file config/crawler.conf contains information that tells the Data Crawler which files to use for its crawl (input adapter), where to send the collection of crawled files after the crawl finishes (output adapter), and other crawl management options.

All file paths are relative to the config directory, except where noted.

To access the in-product manual for the crawler.conf file, with the most up-to-date information, type the following command from the Crawler installation directory: man crawler.conf

The options that can be set in this file are:



 Input adapter 



* class - Internal use only; defines the Data Crawler input adapter class. The default value is: com.ibm.watson.crawler.connectorframeworkinputadapter.Crawl
* config - Internal use only; defines the connector framework configuration. The default configuration key within this block to pass to the chosen input adapter is: connector_framework

The connector framework is what allows you to talk to your data.
Security constraints might prevent you from pulling images from the icr.io/continuous-delivery/pipeline container registry. In such scenarios, complete the following steps:



1. Provision the container images on a supported container registry.
2. Install the deployment.yaml file to reference the container images in this container registry.
3. For each container image that is referenced in the regular deployment yaml file, complete the following steps:



* Docker pull the image to a local Dockerfile.
* Docker tag the image with the new reference on the supported container registry.
* Docker push this new image.



You can obtain the deployment yaml file from https://private-worker-service.$region.devops.cloud.ibm.com/install.
4. Replace the reference to each image in the installation file with the tag for the new image.
5. Run the following command to install the private worker by using the specific container registry: kubectl apply –filename updated_deployment.yaml.
6. Continue the [installation](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-install-private-workers&interface=ui).







 How do I provision and update the private worker installation file for IBM Cloud® Private? 

If your pipeline worker is installed on IBM Cloud Private, you can use the following script to provision and update the private worker installation file.

#!/bin/bash
region=${region:-"us-south"}
target_cr="mycluster.icp:8500"
install_filename="updated-private-worker-install.yaml"
curl -o $install_filename
https://private-worker-service.$region.devops.cloud.ibm.com/install
cat $install_filename | grep -e
* UI
* Terraform







 Deploying SAP NetWeaver 7.x and Db2 on 3-tier IBM Cloud® VPC (Terraform and Ansible) 

You can use Terraform scripts to create a single-tier VPC and create the SAP NW and Db2 distributed 3-tier infrastructure on the VPC. The Terraform scripts use the VPC information that you provide and then call the Ansible playbook to create the SAP architecture on the specified VPC.

Terraform on IBM Cloud® enables predictable and consistent provisioning of IBM Cloud® Virtual Private Cloud (VPC) infrastructure resources so that you can rapidly build complex cloud environments. IBM Cloud VPC infrastructure consists of SAP certified hardware that uses Intel® Xeon CPUs and additional Intel® technologies.

You have two deployment methods to choose from:



* Terraform scripts run from the CLI on your bastion server
* Schematics user interface accessed from the menu on your cloud dashboard





 What is created 

The scripts use the information that you provide for an existing VPC and deploy NW7.X with Db2 3-tier. For more information about this architecture, see [SAP NetWeaver 7.x on UNIX with Db2 on IBM Cloud® VPC](https://cloud.ibm.com/docs/sap?topic=sap-sap-refarch-nw-db2). You specify the information for the VPC to use in the input.auto.tfvars file.

The scripts call the Ansible Playbook to install the SAP architecture.





 Script files 

The configuration and script files are provided on GitHub. Each supported interface for the SAP solution installation has its own folder in the GitHub repository:



* Using the Schematics user interface on IBM Cloud - [GitHub repository for IBM Schematics](https://github.com/IBM-Cloud/sap-netweaver-abap-db2-distributed/tree/main/schematics).







 Schematics deployment 

When you run the scripts with the Schematics interface, you:



* Enter Workspace information.
* Enter the GitHub path.
* Modify the parameters in the Schematics interface.
name: jumbo-apply
namespace: kube-system
labels:
tier: management
app: jumbo-apply
spec:
selector:
matchLabels:
name: jumbo-apply
template:
metadata:
labels:
name: jumbo-apply
spec:
hostNetwork: true
hostPID: true
hostIPC: true
tolerations:
- operator: Exists
initContainers:
- command:
- sh
- -c
- ip link set dev bond0 mtu 9000;ip link set dev bond1 mtu 9000; Update this command based on your worker node type.
image: alpine:3.6
imagePullPolicy: IfNotPresent
name: iplink
resources: {}
securityContext:
privileged: true
capabilities:
add:
- NET_ADMIN
volumeMounts:
- name: modifysys
mountPath: /sys
containers:
- resources:
requests:
cpu: 0.01
image: alpine:3.6
name: sleepforever
command: ["/bin/sh", "-c"]
args:
- >
while true; do
sleep 100000;
done
volumes:
- name: modifysys
hostPath:
path: /sys
Show more



 Updating the Calico installation 

After [applying the DaemonSet to increase the Calico plug-in MTU](https://cloud.ibm.com/docs/openshift?topic=openshift-kernelcalico-mtu), complete the following steps to update the Calico installation.

To run your Red Hat OpenShift cluster, make sure that the MTU is equal to or greater than 1450 bytes.



1. Edit the default Calico installation resource.

oc edit installation default -n calico-system
2. In the spec.calicoNetwork section, change the value of the mtu field.

...
Download the latest 4.x OpenShift CLI (oc) from [https://mirror.openshift.com/pub/openshift-v4/clients/ocp/stable/](https://mirror.openshift.com/pub/openshift-v4/clients/ocp/stable/).
2. Extract openshift-client-linux.tar.gz:

tar zxvf openshift-client-linux.tar.gz oc
3. Move the oc binary to your PATH.

sudo mv ./oc /usr/local/bin/oc
4. Verify the installation with:

oc version







 Helm 3 



1. Download helm from [https://github.com/helm/helm/releases/latest](https://github.com/helm/helm/releases/latest).
2. Uncompress the downloaded archive.
3. Move the helm binary to your PATH.

sudo mv ./linux-amd64/helm /usr/local/bin/helm
4. Verify the installation with:

helm version







 Terraform 



1. Download terraform from [https://www.terraform.io/downloads.html](https://www.terraform.io/downloads.html).
2. Uncompress the downloaded archive.
3. Move the terraform binary to your PATH.

sudo mv ./terraform /usr/local/bin/terraform
4. Verify the installation with:

terraform version



To manage IBM Cloud resources with Terraform, you also need to install the IBM Cloud Provider. Starting with Terraform 0.13, the provider can be automatically downloaded from Terraform plugin registry.
Setting up the Portworx key-value store 



 Setting up a key-value store for Portworx metadata 

Decide on the key-value store that you want to use to store Portworx metadata.

Before you begin, review the [Planning your Portworx setup section](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_plan).

The Portworx key-value store serves as the single source of truth for your Portworx cluster. If the key-value store is not available, then you can't work with your Portworx cluster to access or store your data. Existing data is not changed or removed when the Portworx database is unavailable.

To set up your key-value store, choose between the following options.



* [Automatically set up a key-value database (KVDB) during the Portworx installation](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_kv_store).
* [Set up a Databases for etcd service instance](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_kv_store).







 Using the Portworx key-value database 

Automatically set up a key-value database (KVDB) during the Portworx installation that uses the space on the additional local disks that are attached to your worker nodes.

You can keep the Portworx metadata inside your cluster and store it along with the operational data that you plan to store with Portworx by using the internal key-value database (KVDB) that is included in Portworx. For general information about the internal Portworx KVDB, see the [Portworx documentation](https://docs.portworx.com/concepts/internal-kvdb/).
Refer to [VNC documentation](http://searchnetworking.techtarget.com/definition/virtual-network-computing) for an overview on its functions if you are not familiar with it.



1. Use the following commands to install a VNC server.



[root@sdb192 ] yum install tigervnc-server



2. Use the following command to install the X11 window manager, twm, which is included in the Linux distribution.



[root@sdb192 ] yum install twm



3. Install a terminal emulator, for example, xterm.



[root@sdb192 ] yum install xterm



4. Start the VNC server from the command line.



[root@sdb192 ] vncserver

You now require a VNC client program. Multiple implementations are available for all operating systems at no cost. Typically, you need port 590X (where X is the number of the servers that are running, starting at 1) to be accessible from your client.

You might have to start an xterm from the background menu of twm. You can start SWPM (sapinst) from the xterm.





 Installing SAP software 

After you download the installation media, follow the standard SAP installation procedure that is documented in the SAP installation guide for your SAP version and components, and the corresponding SAP Notes.

You can start SAP SWPM from the xterm, and run the installation steps.



 Installing the SAP software in a three-tier environment 

Follow the steps in SAP's SWPM for a three-tier setup.



1. Select Distributed System and install the ASCS and the database on the database server.
2. Install the Application Server ABAP on the application server. Be sure to use the private addresses for the ASCS and the database hostnames during installation of the application server.



The use of the private addresses and hostnames assures that network traffic between the application server and ASCS, or database, passes through the private network and not through the public network.









 Step 5: Sample multipath.conf