vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Use these steps to install the Terraform CLI.



1. Create a terraform folder on your local machine, and navigate to your terraform folder.

mkdir terraform && cd terraform
2. Download the [Terraform version](https://releases.hashicorp.com/terraform) that you want. The IBM Cloud Provider plug-in for Terraform currently supports Terraform stable version 1.x.x. For more information, about the supported Terraform version, see [list of Terraform version](https://cloud.ibm.com/docs/schematics?topic=schematics-migrating-terraform-version).
3. Extract the Terraform zip file and copy the files to your terraform directory.
4. Set the environment PATH variable to your terraform folder.

export PATH=$PATH:$HOME/terraform
5. Verify that the installation is successful by using a terraform command.

terraform

Example output:

Usage: terraform [global options] <subcommand> [args]

The available commands for execution are listed below.
The primary workflow commands are given first, followed by
less common or more advanced commands.

Main commands:
init Prepare your working directory for other commands
validate Check whether the configuration is valid
plan Show changes required by the current configuration
apply Create or update infrastructure
destroy Destroy previously-created infrastructure

All other commands:
console Try Terraform expressions at an interactive command prompt
fmt Reformat your configuration in the standard style
force-unlock Release a stuck lock on the current workspace
get Install or upgrade remote Terraform modules
graph Generate a Graphviz graph of the steps in an operation
import Associate existing infrastructure with a Terraform resource
login Obtain and save credentials for a remote host
logout Remove locally-stored credentials for a remote host
output Show output values from your root module
providers Show the providers required for this configuration
refresh Update the state to match remote systems
show Show the current state or a saved plan
state Advanced state management
taint Mark a resource instance as not fully functional
By default, these will be $MQ_INSTALLATION_PATH/samp/jms/samples on Linux and %MQ_INSTALLATION_PATH%\tools\jms\samples on Windows
2. Use any editor to open the simple/JmsPut.java program.
3. Add following new properties to the jms program, just after creating JMS ConnectionFactory instance.

System.setProperty("javax.net.ssl.keyStore", "/Users/you/store/key.kdb");
System.setProperty("javax.net.ssl.keyStorePassword", "my_store_password");

cf.setStringProperty(WMQConstants.USERID, "Your app user ID");
cf.setStringProperty(WMQConstants.PASSWORD, "Your APIKEY");
cf.setStringProperty(WMQConstants.WMQ_SSL_CIPHER_SPEC, "ANY_TLS12_OR_HIGHER");
cf.setStringProperty(WMQConstants.WMQ_CHANNEL, "CLOUD.APP.SVRCONN");
cf.setIntProperty(WMQConstants.WMQ_CONNECTION_MODE, WMQConstants.WMQ_CM_CLIENT);

<-- <ul> -->

* The property keyStore should be the full path to the keystore which you created in Enabling TLS security for MQ channels in MQ on Cloud]Enabling TLS security for MQ channels in MQ on Cloud 1]!! !!! ! ! ! !
[ERROR] [2021-03-04 05:12:44-0657] Exiting due to error (Storage class is immutable. Module ibm-watson-gateway-operator x86_64 from Assembly portworx-shared-gp3 was installed with ibm-watson-gateway-operator x86_64, but new install/upgrade command is requesting portworx-db-gp3-sc. If you installed the assembly with a different storage class, please upgrade it individually.). Please check /ibm/cpd-cli-workspace/logs/CPD-2021-03-04T05-12-04.log for details
[ERROR] 2021-03-04T05:12:44.659615Z Execution error: exit status 1

This error message is generated because the storage class that was used for installation is different than the one that was used during the upgrade. This discrepancy results from a different add-on installing the dependency operators because the storage class dependency operators of the different add-on were recorded as the ones that were used for installation. To work around this issue, you must upgrade the following subassemblies individually:



* Upgrade the Watson gateway operator:

./cpd-cli upgrade --repo ./repo.yaml --assembly ibm-watson-gateway-operator --arch Cluster_architecture --namespace <Project> --transfer-image-to <Registry_location> --cluster-pull-prefix <Registry_from_cluster> --ask-pull-registry-credentials --ask-push-registry-credentials
* Upgrade Minio operator:

./cpd-cli upgrade --repo ./repo.yaml --assembly ibm-minio-operator --namespace <Project> --transfer-image-to <Registry_location> --cluster-pull-prefix <Registry_from_cluster> --ask-pull-registry-credentials --ask-push-registry-credentials
* Upgrade RabbitMQ operator:
The labels for the predefined cluster roles are as follows.<br><br><br><br> * IAM Manager service access role, scoped to a namespace: rbac.authorization.k8s.io/aggregate-to-admin: "true"<br> * IAM Writer service access role: rbac.authorization.k8s.io/aggregate-to-edit: "true"<br> * IAM Reader service access role: rbac.authorization.k8s.io/aggregate-to-view: "true"<br><br><br> 
 rules.apiGroups Specify the Kubernetes [API groups](https://kubernetes.io/docs/reference/using-api/api-groups) that you want users to be able to interact with, such as "apps", "batch", or "extensions". For access to the core API group at REST path api/v1, leave the group blank: [""]. 
 rules.resources Specify the Kubernetes [resource types](https://kubernetes.io/docs/reference/kubectl/cheatsheet/) to which you want to grant access, such as "daemonsets", "deployments", "events", or "ingresses". 
 rules.verbs Specify the types of [actions](https://kubectl.docs.kubernetes.io/) that you want users to be able to do, such as "get", "list", "describe", "create", or "delete". 



2. Create the cluster role in your cluster. Any users that have a role binding to the admin cluster role now have the additional permissions from the view-pod-metrics cluster role.

oc apply -f <cluster_role_file.yaml>
3. Follow up with users that have the admin cluster role. Ask them to [refresh their cluster configuration](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster) and test the action, such as oc top pods.









 Checking user permissions
If you plan to connect your cluster to on-premises networks through IBM Cloud® Direct Link or a VPN service, you can avoid subnet conflicts by specifying a custom subnet CIDR that provides the private IP addresses for your pods. When you choose a subnet size, consider the size of the cluster that you plan to create and the number of worker nodes that you might add in the future. The subnet must have a CIDR of at least /23, which provides enough pod IPs for a maximum of four worker nodes in a cluster. For larger clusters, use /22 to have enough pod IP addresses for eight worker nodes, /21 to have enough pod IP addresses for 16 worker nodes, and so on. Note that the pod and service subnets can't overlap. The service subnet is in the 172.21.0.0/16 range by default. The subnet that you choose must be within one of the following ranges:



* 172.17.0.0 - 172.17.255.255
* 172.21.0.0 - 172.31.255.255
* 192.168.0.0 - 192.168.254.255
* 198.18.0.0 - 198.19.255.255



--service-subnet
: All services that are deployed to the cluster are assigned a private IP address in the 172.21.0.0/16 range by default. If you plan to connect your cluster to on-premises networks through IBM Cloud Direct Link or a VPN service, you can avoid subnet conflicts by specifying a custom subnet CIDR that provides the private IP addresses for your services.
: The subnet must be specified in CIDR format with a size of at least /24, which allows a maximum of 255 services in the cluster, or larger. The subnet that you choose must be within one of the following ranges:



* 172.17.0.0 - 172.17.255.255
* 172.21.0.0 - 172.31.255.255
* 192.168.0.0 - 192.168.254.255
* 198.18.0.0 - 198.19.255.255
The labels for the predefined cluster roles are as follows.<br><br><br><br> * IAM Manager service access role, scoped to a namespace: rbac.authorization.k8s.io/aggregate-to-admin: "true"<br> * IAM Writer service access role: rbac.authorization.k8s.io/aggregate-to-edit: "true"<br> * IAM Reader service access role: rbac.authorization.k8s.io/aggregate-to-view: "true"<br><br><br> 
 rules.apiGroups Specify the Kubernetes [API groups](https://kubernetes.io/docs/reference/using-api/api-groups) that you want users to be able to interact with, such as "apps", "batch", or "extensions". For access to the core API group at REST path api/v1, leave the group blank: [""]. 
 rules.resources Specify the Kubernetes [resource types](https://kubernetes.io/docs/reference/kubectl/cheatsheet/) to which you want to grant access, such as "daemonsets", "deployments", "events", or "ingresses". 
 rules.verbs Specify the types of [actions](https://kubectl.docs.kubernetes.io/) that you want users to be able to do, such as "get", "list", "describe", "create", or "delete". 



2. Create the cluster role in your cluster. Any users that have a role binding to the admin cluster role now have the additional permissions from the view-pod-metrics cluster role.

kubectl apply -f <cluster_role_file.yaml>
3. Follow up with users that have the admin cluster role. Ask them to [refresh their cluster configuration](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster) and test the action, such as kubectl top pods.









 Checking user permissions
--service-instance <cluster_ID> To restrict the policy to a particular cluster, enter the cluster's ID. To get your cluster ID, run ibmcloud oc clusters. If you don't include the service instance, the access policy grants the service ID access to all your clusters, Kubernetes and Red Hat OpenShift. You can also scope the access policy to a region (--region) or resource group (--resource-group-name). 



3. Create an API key for the service ID. Name the API key similar to your service ID, and include the service ID that you previously created, <cluster_name>-id. Be sure to give the API key a description that helps you retrieve the key later. Save your API key in a secure location. You can't retrieve the API key again. If you want to export the output to a file on your local machine, include the --file <path>/<file_name> option.

ibmcloud iam service-api-key-create <cluster_name>-key <service_ID> --description "API key for service ID <service_ID> in Red Hat OpenShift cluster <cluster_name>"

Example output

Please preserve the API key! It can't be retrieved after it's created.

Name <cluster_name>-key
Description API key for service ID <service_ID> in Red Hat OpenShift cluster <cluster_name>
Bound To crn:v1:bluemix:public:iam-identity::a/1bb222bb2b33333ddd3d3333ee4ee444::serviceid:ServiceId-ff55555f-5fff-6666-g6g6-777777h7h7hh
Created At 2019-02-01T19:06+0000
API Key i-8i88ii8jjjj9jjj99kkkkkkkkk_k9-llllll11mmm1
Locked false
* Size the cluster to provide enough capacity for your workloads.
* Design a cluster to meet the high availability, disaster recovery, and compliance standards of your company.
* Secure the cluster by setting up user permissions and limiting actions within the cluster to protect your compute resources, your network, and data.
* Plan and manage network communication between infrastructure components to ensure network security, segmentation, and compliance.
* Plan persistent storage options to meet data residency and data protection requirements.



The cluster admin persona must have a broad knowledge that includes compute, network, storage, security, and compliance. In a typical company, this knowledge is spread across multiple specialists, such as System Engineers, System Administrators, Network Engineers, Network Architects, IT Managers, or Security and Compliance Specialists. Consider assigning the cluster admin role to multiple people in your company so that you have the required knowledge to successfully operate your cluster.

What are an app developer's main tasks and technical skills?
: As a developer, you design, create, secure, deploy, test, run, and monitor cloud-native, containerized apps in an Red Hat OpenShift cluster. To create and run these apps, you must be familiar with the concept of microservices, the [12-factor app](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_deploy12factor) guidelines, [Docker and containerization principles](https://www.docker.com/), and available [Red Hat OpenShift deployment options](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_deploy).
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
oc-api-via-nlb LoadBalancer 172.21.150.118 10.186.92.42 443:32235/TCP 10m <none>
...



5. On the client machines where you or your users run oc commands, add the NLB IP address and the private cloud service endpoint URL to the /etc/hosts file. Do not include any ports in the IP address and URL and don't include https:// in the URL.



* For macOS and Linux users:

sudo nano /etc/hosts
* For Windows users:

notepad C:WindowsSystem32driversetchosts

Depending on your local machine permissions, you might need to run Notepad as an administrator to edit the hosts file.

Example text to add:

10.186.92.42 c1.private.us-east.containers.cloud.ibm.com



6. Verify that you are connected to the private network through a [VPN](https://cloud.ibm.com/docs/iaas-vpn?topic=iaas-vpn-getting-started) or [IBM Cloud Direct Link](https://cloud.ibm.com/docs/dl?topic=dl-get-started-with-ibm-cloud-dl) connection.
7. Log in to your cluster by choosing from one of the following options.



* Log in as admin:



1. Make sure that you have the [Administrator platform access role for the cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-usersadd_users).
2. Set your command line context for the cluster and download the TLS certificates and permission files for the administrator.

ibmcloud oc cluster config -c <cluster_name_or_ID> --admin --endpoint private
: When VRF or VLAN spanning is enabled, any system that is connected to any of the private VLANs in the same IBM Cloud account can communicate with workers. You can isolate your cluster from other systems on the private network by applying [Calico private network policies](https://cloud.ibm.com/docs/containers?topic=containers-network_policiesisolate_workers). IBM Cloud Kubernetes Service is also compatible with all [IBM Cloud infrastructure firewall offerings](https://www.ibm.com/cloud/network-security). You can set up a firewall, such as a [Virtual Router Appliance](https://cloud.ibm.com/docs/virtual-router-appliance?topic=virtual-router-appliance-about-the-vra), with custom network policies to provide dedicated network security for your standard cluster and to detect and remediate network intrusion.







 Using existing subnets to create a cluster 

When you create a standard cluster, subnets are automatically created for you. However, instead of using the automatically provisioned subnets, you can use existing portable subnets from your IBM Cloud infrastructure account or reuse subnets from a deleted cluster.

Use this option to retain stable static IP addresses across cluster removals and creations, or to order larger blocks of IP addresses. If instead you want to get more portable public or private IP addresses to create network load balancer (NLB) or Ingress application load balancer (ALB) services, see [Adding portable IP addresses](https://cloud.ibm.com/docs/containers?topic=containers-subnetsadding_ips).

All subnets that were automatically ordered during cluster creation are immediately marked for deletion after you delete a cluster, and you can't reuse the subnets to create a new cluster.

Before you begin



* [Log in to your account. If applicable, target the appropriate resource group. Set the context for your cluster.](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster)
A public network gateway is required when you want your cluster to access public endpoints, such as a public URL of another app, or an IBM Cloud service that supports public cloud service endpoints only.
7. Click Create subnet.



4. Use the subnets to [create a cluster](https://cloud.ibm.com/docs/containers?topic=containers-cluster-create-vpc-gen2). Do not delete the subnets that you attach to your cluster during cluster creation or when you add worker nodes in a zone. If you delete a VPC subnet that your cluster used, any load balancers that use IP addresses from the subnet might experience issues, and you might be unable to create new load balancers.







 Creating VPC subnets for classic access from the CLI 



1. In your command line, log in to your IBM Cloud account and target the IBM Cloud region and resource group where you want to create your VPC cluster. For supported regions, see [Creating a VPC in a different region](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-a-vpc-in-a-different-region). The cluster's resource group can differ from the VPC resource group. Enter your IBM Cloud credentials when prompted. If you have a federated ID, use the --sso option to log in.

ibmcloud login -r <region> [-g <resource_group>] [--sso]
2. Create a classic access VPC without default address prefixes. In the output, copy the VPC ID.

ibmcloud is vpc-create <name> --classic-access --address-prefix-management manual
3. For each zone in which you plan to create subnets, create one or more address prefixes.
[Architecture image for a cluster that connects to an on-premises data center on the private network.](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/cs_clusters_planning_extend.png)

Figure 1. Network setup for a cluster that connects to an on-premises data center on the private network



 Worker-to-worker communication for private clusters 

To achieve this setup, you create a cluster by connecting worker nodes to a private VLAN only. To provide connectivity between the cluster master and worker nodes over the private network through the private cloud service endpoint only, your account must be enabled with VRF and enabled to use service endpoints. Because your cluster is visible to any resource on the private network when VRF is enabled, you can isolate your cluster from other systems on the private network by applying Calico private network policies.

Note that you might have subnet conflicts between the default ranges for workers nodes, pods, and services, and the subnets in your on-premises networks. You create your cluster without IBM-provided subnets by including the --no-subnet option. After the cluster is created, you can [add custom subnets](https://cloud.ibm.com/docs/containers?topic=containers-subnetssubnets_custom) to your cluster. Additionally, you can specify a custom subnet CIDR for pods and services by using the --pod-subnet and --service-subnet options in the ibmcloud ks cluster create command when you create your cluster.





 Worker-to-master and user-to-master communication for private clusters
After the account administrator makes these preparations, you might not need to change them each time that you create a cluster. However, each time that you create a cluster, you still want to verify that the current account-level state is what you need it to be.



1. [Create or upgrade your account to a billable account (IBM Cloud Pay-As-You-Go or Subscription)](https://cloud.ibm.com/registration).
2. [Set up an API key for Red Hat OpenShift on IBM Cloud](https://cloud.ibm.com/docs/openshift?topic=openshift-access-creds) in the region and resource groups where you want to create clusters. Assign the API key with the [required service and infrastructure permissions to create clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-access_referencecluster_create_permissions). Are you the account owner? You already have the necessary permissions! When you create a cluster, the API key for that region and resource group is set with your credentials.
3. Verify that you as a user (not just the API key) have the required permissions to create clusters.



1. From the [IBM Cloud console](https://cloud.ibm.com/) menu bar, click Manage > Access (IAM).
2. Click the Users page, and then from the table, select yourself.
3. From the Access policies tab, confirm that you [have the required permissions to create clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-access_referencecluster_create_permissions). Make sure that your account administrator does not assign you the Administrator platform access role at the same time as scoping the access policy to a namespace.



4. If your account uses multiple resource groups, figure out your account's strategy for [managing resource groups](https://cloud.ibm.com/docs/openshift?topic=openshift-access-overviewresource_groups).
Cluster health image v1.1.25 v1.1.26 Updated universal base image (UBI) to the latest 8.4 version to resolve CVEs: [CVE-2021-36222](https://nvd.nist.gov/vuln/detail/CVE-2021-36222), [CVE-2021-37750](https://nvd.nist.gov/vuln/detail/CVE-2021-37750), [CVE-2021-22922](https://nvd.nist.gov/vuln/detail/CVE-2021-22922), [CVE-2021-22923](https://nvd.nist.gov/vuln/detail/CVE-2021-22923), and [CVE-2021-22924](https://nvd.nist.gov/vuln/detail/CVE-2021-22924). 
 etcd v3.3.25 v3.3.26 See the [etcd release notes](https://github.com/etcd-io/etcd/releases/v3.3.26). 
 IBM Cloud File Storage for Classic plug-in and monitor 400 401 Updated universal base image (UBI) to the latest 8.4-210 version to resolve CVEs.
ibmcloud oc ingress domain create --cluster CLUSTER [--is-default] [--domain DOMAIN] [--hostname HOSTNAME] [--ip IP] [--output OUTPUT] [-q] [--secret-namespace NAMESPACE]

-c, --cluster CLUSTER
: Required. The name or ID of the cluster where you want to create the domain.

--is-default
: Optional. Include this option to set the relevant domain as the default domain for the cluster.

--domain DOMAIN
: The domain to create or add to your cluster. This can be a domain that exists in your provider account, or a new domain.

--hostname HOSTNAME
: Optional. For VPC clusters. The hostname to register for the domain.

--ip IP
: Optional. The IP addresses to register for the domain.

--output OUTPUT
: Optional: Prints the command output in JSON format.

--secret-namespace NAMESPACE
: Optional. The namespace that the domain TLS secret is created in. If no namespace is specified, the secret is created in the default namespace.





 Setting up domains with IBM Cloud Internet Services 

Follow the steps to create a domain with IBM Cloud Internet Services.



 Set up service-to-service authorization 

Creating a domain with IBM Cloud Internet Services requires you to [set up service-to-service authorization](https://cloud.ibm.com/docs/account?topic=account-serviceauth&interface=uicreate-auth) for your IBM Cloud Internet Services instance. Set the source service as Kubernetes Service, and the target as Internet services. Assign the Manager role.





 Create a domain 

Create a new domain, or specify an existing domain that you want to add to your cluster. To specify an existing domain, include the full domain name with the external provider zone, such as exampledomain.externalzone.com. To create a new domain, you must still include the external provider zone, but you can customize the subdomain portion, such as custom.exampledomain.externalzone.com.