vania-janet/multiturn-rag-retrieval-data huggingface dataset:
A Development Exec has Developers that use on-premises application tools that slow down prototyping while they wait for hardware procurement.

Red Hat OpenShift on IBM Cloud provides spin-up of compute by using open-source standard technology. After the company moved to Red Hat OpenShift on IBM Cloud, Developers have access to DevOps friendly tools, such as portable and easily shared containers.

Then, Developers can experiment easily, pushing changes to Development and Test systems quickly with open toolchains. Their application development tools get a new face when they add on AI cloud services to apps with a click.



 Context 

Streamlining developer productivity and deploying AI tools to partners 4 times faster**



* Disruption is rampant in the payment industry that also has dramatic growth both in the consumer and business-to-business segments. But updates to payment tools were slow.
* Cognitive features are needed to target fraudulent transactions in new and faster ways.
* With the growing numbers of partners and their transactions, the tool traffic increases, but their infrastructure budget needs to decrease, by maximizing efficiency of the resources.
* Their technical debt is growing, not shrinking from an inability to release quality software to keep up with market demands.
* Capital expense budgets are under tight control, and IT feels they don't have the budget or staff to create the testing and staging landscapes with their in-house systems.
* Security is increasingly a primary concern, and this concern only adds to the delivery burden that all cause even more delays.







 Solution 

The Development Exec is faced with many challenges in the dynamic payment industry. Regulations, consumer behaviors, fraud, competitors, and market infrastructures are all rapidly evolving. Fast-paced development is essential to being part of the future payment world.

Their business model is to provide payment tools to business partners, so they can help these financial institutions and other organizations deliver security-rich digital payment experiences.

They need a solution that helps the Developers and their business partners:



* FRONT-END TO PAYMENT TOOLS: fee systems, payment tracking including cross-border, regulatory compliance, biometrics, remittance, and more
* REGULATION-SPECIFIC FEATURES: each country has unique regulations so that the overall toolset might look similar but show country-specific benefits
* DEVELOPER-FRIENDLY TOOLS that accelerate roll-out of features and bug fixes
5.2.8 Red Hat OpenShift on IBM Cloud can optionally [configure security context constraints](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_scc). 
 5.2.9 Red Hat OpenShift on IBM Cloud can optionally [configure security context constraints](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_scc). 
 5.3.2 Red Hat OpenShift on IBM Cloud has a set of [default Calico network policies defined](https://cloud.ibm.com/docs/openshift?topic=openshift-network_policiesdefault_policy) and [additional network policies can optionally be added](https://cloud.ibm.com/docs/openshift?topic=openshift-network_policiesadding_network_policies). 
 5.4.1 Red Hat OpenShift on IBM Cloud deploys some system components that could prefer using secrets as files over secrets as environment variables. 
 5.4.2 Red Hat OpenShift on IBM Cloud can optionally [enable a Kubernetes Key Management Service (KMS) provider](https://cloud.ibm.com/docs/openshift?topic=openshift-encryptionkms). 
 5.5.1 Red Hat OpenShift on IBM Cloud can optionally [enable image security enforcement](https://cloud.ibm.com/docs/openshift?topic=openshift-imagesportieris-image-sec). 
 5.6.2 Red Hat OpenShift on IBM Cloud does not annotate all pods with [seccomp profiles](https://kubernetes.io/docs/concepts/security/pod-security-policy/). 
 5.6.3 Red Hat OpenShift on IBM Cloud deploys some system components that do not set a [pod or container securityContext](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/).
Accelerated development is a key win for the Exec. With the use of modern containers, Developers can experiment easily in the languages of their choice, pushing changes to Development and Test systems, scaled out on separate clusters. Those pushes were automated with open toolchains and IBM Cloud® Continuous Delivery. No longer were updates to the tools languishing in slow, error-prone build processes. They can deliver incremental updates to their tools, daily or even more frequently.

Also, logging and monitoring for the tools, especially where they used Watson AI, rapidly integrate into the system. Developers don’t waste time building complex logging systems, just to be able to troubleshoot their live systems. A key factor for less staffing costs is that IBM manages Kubernetes, so the Developers can focus on better payment tools.

Security first: With bare metal for Red Hat OpenShift on IBM Cloud, the sensitive payment tools now have familiar isolation but within the flexibility of public cloud. Scans for vulnerabilities are run continuously.



 Step 1: Lift and shift to secure compute 



* Migrate virtual machine images to container images that run in Red Hat OpenShift on IBM Cloud in the public IBM Cloud. Deploy IBM Cloud Pak for Applications, so that developers have their familiar application development tools on the cloud.
* From that core, Vulnerability Advisor provides image, policy, container, and packaging vulnerability scanning.
* Private data center / on-premises capital costs are greatly reduced and replaced with a utility computing model that scales based on workload demand.
* Consistently enforce policy-driven authentication to your services and APIs with a simple Ingress annotation. With declarative security you can ensure user authentication and token validation by using App ID.







 Step 2: Operations and connections to existing payment systems back-end 



* Use IBM Secure Gateway to maintain secure connections to remaining on-premises tool systems.
* Provide standardized DevOps dashboards and practices through Kubernetes.
* After Developers build and test apps in Development and Test clusters, they use the IBM Cloud® Continuous Delivery toolchains to deploy apps into the Red Hat OpenShift on IBM Cloud clusters across the globe.
* Built-in HA tools in Red Hat OpenShift on IBM Cloud balance the workload within each geographic region, including self-healing and load balancing.
Deploy from Red Hat Marketplace 

The Red Hat Marketplace can be used to deploy the IBM® Blockchain Platform 2.5.4 operator onto a Kubernetes cluster on OpenShift Container Platform 4.4+. This operator deploys instances of the certificate authority (CA), peer, ordering nodes and the IBM Blockchain Platform console that uses to manage the blockchain components on your network. This deployment option is available for OpenShift clusters that are running in IBM Cloud or your cloud.



 What is Red Hat Marketplace? 

Red Hat Marketplace is available directly from your OpenShift web console. It provides an open cloud catalog that makes it easier to discover and access certified software for container-based environments in public clouds. With automated deployment, software is immediately available to deploy on any Red Hat OpenShift cluster, providing a fast, integrated experience. Discover and buy certified software, and quickly deploy. Access open source and proprietary software, with responsive support, streamlined billing and contracting, simplified governance, and single-dashboard visibility across clouds. Built in partnership by Red Hat and IBM, this marketplace helps organizations deliver enterprise software and improve workload portability.

Red Hat Marketplace provides a simplified alternative method for deploying an instance of the IBM Blockchain Platform to your cluster instead of the [manual deployment steps](https://cloud.ibm.com/docs/blockchain-sw-254?topic=blockchain-sw-254-deploy-ocp) or by using [Ansible playbook](https://cloud.ibm.com/docs/blockchain-sw-254?topic=blockchain-sw-254-ansible) scripts.

With just a few simple steps, you can get started with the IBM Blockchain Platform. After you install the operator to your OpenShift project, you can create a subscription that allows you to deploy the blockchain console UI.

Currently, you cannot deploy certificate authorities (CAs), peers, and ordering nodes directly, then, use the console to deploy those nodes instead. This tutorial includes only instructions for installing the console.

To learn more about the Marketplace see the [Red Hat documentation](https://marketplace.redhat.com).





 Limitations
Supported Satellite-enabled IBM Cloud services 

Learn about what services are supported by IBM Cloud Satellite.



Table 1. Supported managed services for Satellite

 Service Description of support Supported by RHCOS hosts 

 Red Hat OpenShift on IBM Cloud You can create Red Hat OpenShift on IBM Cloud clusters in a Satellite location, and use the hosts of your own infrastructure that you added to your location as the worker nodes for the cluster. See [Creating Red Hat OpenShift clusters in Satellite](https://cloud.ibm.com/docs/openshift?topic=openshift-satellite-clusters). Yes, for Red Hat OpenShift version 4.9 and later. 
 IBM Cloud Databases (ICD) ICD enabled by Satellite supports<br><br><br><br> * Databases for etcd<br> * Databases for PostgreSQL<br> * Databases for Redis<br> * Messages for RabbitMQ. <br> See [IBM Cloud Databases (ICD) enabled by IBM Cloud Satellite](https://cloud.ibm.com/docs/cloud-databases?topic=cloud-databases-satellite-get-started).<br><br><br> No 
 IBM Cloud Object Storage IBM Cloud Object Storage offers users the flexibility to run a managed Object Storage service on client-owned on-premises infrastructure, edge locations or third-party public cloud infrastructure. See [About Object Storage for Satellite](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-about-cos-satellite). No 
 IBM Key Protect for IBM Cloud IBM Key Protect for IBM Cloud on Satellite is a dedicated service that allows users to more fully control their own encryption keys by deploying Key Protect into a Satellite location where users control their own infrastructure. See [About Key Protect for Satellite](https://cloud.ibm.com/docs/key-protect?topic=key-protect-satellite-about). No 
 IBM® Event Streams for IBM Cloud® Event Streams is a high-throughput message bus built with Apache Kafka. It is optimized for event ingestion into IBM Cloud and event stream distribution between your services and applications.
5.2.9 Red Hat OpenShift on IBM Cloud can optionally configure [Red Hat OpenShift security context constraints](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_scc) and [Kubernetes pod security admission](https://kubernetes.io/docs/concepts/security/pod-security-admission/) which are similar to the deprecated [Kubernetes pod security policies](https://kubernetes.io/docs/concepts/security/pod-security-policy/). 
 5.3.2 Red Hat OpenShift on IBM Cloud has a set of [default Calico network policies defined](https://cloud.ibm.com/docs/openshift?topic=openshift-network_policiesdefault_policy) and [additional network policies can optionally be added](https://cloud.ibm.com/docs/openshift?topic=openshift-network_policiesadding_network_policies). 
 5.4.1 Red Hat OpenShift on IBM Cloud deploys some system components that could prefer using secrets as files over secrets as environment variables. 
 5.4.2 Red Hat OpenShift on IBM Cloud can optionally [enable a Kubernetes Key Management Service (KMS) provider](https://cloud.ibm.com/docs/openshift?topic=openshift-encryptionkms). 
 5.5.1 Red Hat OpenShift on IBM Cloud can optionally [enable image security enforcement](https://cloud.ibm.com/docs/openshift?topic=openshift-imagesportieris-image-sec). 
 5.6.2 Red Hat OpenShift on IBM Cloud does not annotate all pods with [seccomp profiles](https://kubernetes.io/docs/concepts/security/pod-security-policy/seccomp).
Display and copy the oc login token command into your command line to authenticate by using the CLI.



You can explore the following areas of the Red Hat OpenShift web console.

Administrator perspective
: The Administrator perspective is available from the side navigation menu perspective switcher. From the Administrator perspective, you can manage and set up the components that your team needs to run your apps, such as projects for your workloads, networking, and operators for integrating IBM, Red Hat, 3rd party, and custom services into the cluster. For more information, see [Viewing cluster information](http://docs.openshift.com/container-platform/4.11/web_console/using-dashboard-to-get-cluster-information.html) in the Red Hat OpenShift documentation.

Developer perspective
: The Developer perspective is available from the side navigation menu perspective switcher. From the Developer perspective, you can add apps to your cluster in a variety of ways, such as from Git repositories,container images, uploaded YAML files, operator catalogs, and more. The Topology view presents a unique way to visualize the workloads that run in a project and navigate their components from sidebars that aggregate related resources, including pods, services, routes, and metadata. For more information, see [Developer perspective]([https://docs.openshift.com/container-platform/4.11/web_console/web-console-overview.html](https://docs.openshift.com/container-platform/4.11/web_console/web-console-overview.html){: external} in the Red Hat OpenShift documentation.
Any costs that incur by using a third-party open source integration are not included in your monthly IBM Cloud bill.

Installing third-party open source integrations or Helm charts from the Kubernetes community might change the default cluster configuration and can bring your cluster into an unsupported state. If you run into an issue with using any of these tools, consult the Kubernetes community or the service provider directly.





 Extending Red Hat OpenShift API and software with CRDs and Operators 

You might use custom resource definitions (CRDs) to extend the Red Hat OpenShift API to create and orchestrate custom objects in your cluster. Operators combine custom resources and controllers to automate the lifecycle of app, such as installing and rolling out updates to a customized app from a catalog in your cluster.

For more information, see [Operators](https://cloud.ibm.com/docs/openshift?topic=openshift-operators).
5.1.3 Red Hat OpenShift on IBM Cloud deploys some system components that could have their Kubernetes resource access further restricted. 
 5.1.5 Red Hat OpenShift on IBM Cloud does not set automountServiceAccountToken: false for each default service account. 
 5.1.6 Red Hat OpenShift on IBM Cloud deploys some system components that could set automountServiceAccountToken: false. 
 5.2.1 Red Hat OpenShift on IBM Cloud can optionally [configure security context constraints](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_scc). 
 5.2.2 Red Hat OpenShift on IBM Cloud can optionally [configure security context constraints](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_scc). 
 5.2.3 Red Hat OpenShift on IBM Cloud can optionally [configure security context constraints](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_scc). 
 5.2.4 Red Hat OpenShift on IBM Cloud can optionally [configure security context constraints](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_scc). 
 5.2.5 Red Hat OpenShift on IBM Cloud can optionally [configure security context constraints](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_scc). 
 5.2.6 Red Hat OpenShift on IBM Cloud can optionally [configure security context constraints](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_scc).
* Set up your environment and all the software that you need for your Red Hat OpenShift Container Platform installation, such as Terraform on IBM Cloud, IBM Cloud Provider plug-in, and the Terraform on IBM Cloud OpenShift project.
* Retrieve IBM Cloud credentials, configure the IBM Cloud Provider plug-in, and define your Red Hat OpenShift Container Platform classic infrastructure components.
* Provision IBM Cloud classic infrastructure for your Red Hat OpenShift Container Platform components by using Terraform on IBM Cloud.
* Install Red Hat OpenShift Container Platform on IBM Cloud classic infrastructure.
* Deploy the nginx app in your OpenShift cluster and expose this app to the public.







 Audience 

This tutorial is intended for network administrators who want to deploy Red Hat OpenShift Container Platform on IBM Cloud classic infrastructure.





 Prerequisites 



* If you do not have one, create an IBM Cloud [Pay-As-You-Go or Subscription IBM Cloud account](https://cloud.ibm.com/registration).
* Make sure that you have an existing Red Hat account that has an [active OpenShift subscription](https://access.redhat.com/products/red-hat-openshift-container-platform).
* Install [Docker and the IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-getting-started).







 Lesson 1: Configure your environment 

In this tutorial, you provision IBM Cloud classic infrastructure for the Red Hat OpenShift Container Platform by using Terraform on IBM Cloud. Before you can start the classic infrastructure provisioning process, you must ensure that you set up Terraform on IBM Cloud, the IBM Cloud Provider plug-in, and the Terraform on IBM Cloud OpenShift project.



1. Create a Docker container that installs Terraform on IBM Cloud and the IBM Cloud Provider plug-in. To execute Terraform on IBM Cloud commands, you must be logged in to the container.
For more information about supported regions, see [Locations](https://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zonesregions-and-zones).





 Is the service highly available? 

Yes. By default, Red Hat OpenShift on IBM Cloud sets up many components such as the cluster master with replicas, anti-affinity, and other options to increase the high availability (HA) of the service. You can increase the redundancy and failure toleration of your cluster worker nodes, storage, networking, and workloads by configuring them in a highly available architecture. For an overview of the default setup and your options to increase HA, see [High availability for Red Hat OpenShift on IBM Cloud](https://cloud.ibm.com/docs/openshift?topic=openshift-ha).

For the latest HA service level agreement terms, refer to the [IBM Cloud terms of service](https://cloud.ibm.com/docs/overview?topic=overview-slas). Generally, the SLA availability terms require that when you configure your infrastructure resources in an HA architecture, you must distribute them evenly across three different availability zones. For example, to receive full HA coverage under the SLA terms, you must [set up a multizone cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-ha_clustersmz-clusters) with a total of at least 6 worker nodes, two worker nodes per zone that are evenly spread across three zones.





 What compliance standards does the service meet? 

IBM Cloud is built by following many data, finance, health, insurance, privacy, security, technology, and other international compliance standards. For more information, see [IBM Cloud compliance](https://cloud.ibm.com/docs/overview?topic=overview-compliance).

To view detailed system requirements, you can run a [software product compatibility report for Red Hat OpenShift on IBM Cloud](https://www.ibm.com/software/reports/compatibility/clarity/softwareReqsForProduct.html).
* For Red Hat OpenShift on IBM Cloud on Classic infrastructure follow the [Creating a standard classic cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-clustersclusters_standard) instructions.



* Select a Resource group
* Select a Geography
* Select Single zone as Availability
* Choose a Datacenter





6. Under Worker pool,



* Select 4 vCPUs 16GB Memory as the flavor
* Select 2 Worker nodes per data center for this tutorial (classic only: Leave Encrypt local disk)



7. Under Resource details,Set Cluster name to <your-initials>-myopenshiftcluster by replacing <your-initials> with your own initials.
8. Click Create to provision a Red Hat OpenShift on IBM Cloud cluster.



Take a note of the resource group selected above. This same resource group will be used for all resources in this lab.



 Access the cluster using the IBM Cloud Shell 

The [Red Hat OpenShift on IBM Cloud Container Platform CLI](https://docs.openshift.com/container-platform/4.12/cli_reference/openshift_cli/getting-started-cli.html) exposes commands for managing your applications, as well as lower level tools to interact with each component of your system. The CLI is available using the oc command.

To avoid installing the command line tools, the recommended approach is to use the IBM Cloud Shell.

IBM Cloud Shell is a cloud-based shell workspace that you can access through your browser. It's preconfigured with the full IBM Cloud CLI and many plug-ins and tools that you can use to manage apps, resources, and infrastructure.

In this step, you'll use the IBM Cloud shell and configure oc to point to the cluster assigned to you.



1. When the cluster is ready, on the cluster overview page click on OpenShift web console to open the console. Make sure you don't close this window/tab
2.
For a list of available operating sysems by cluster version, see [Available Red Hat OpenShift versions](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_versionsopenshift_versions_available). Note that to use your RHCOS hosts in your clusters, you must create a Red Hat CoreOS-enabled location and a cluster that runs version 4.9 or later. If no option is specified, the default [operating system that corresponds to the cluster version](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_versionsopenshift_versions_available) is used.

--pod-subnet SUBNET
: Optional. All pods that are deployed to a worker node are assigned a private IP address in the 172.30.0.0/16 range by default. You can avoid subnet conflicts with the network that you use to connect to your location 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.
: The subnet that you choose must be within one of the following ranges.



* 172.16.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



: Note that the pod and service subnets can't overlap. The service subnet is in the 172.21.0.0/16 range by default. This value can't be set to the value of the related location's pod-subnet or service-subnet.