vania-janet/multiturn-rag-retrieval-data huggingface dataset:
https://cloud.ibm.com/devops/toolchains/6ffb568a-e48f-4e27-aed0-00ca931dde66?env_id=ibm:yp:us-south

If you copy and paste the link that is returned by the ibmcloud dev create command, you can also access your CD Toolchain. You can access that from the console later, in case you missed capturing the link. Further information follows, as the process continues creating application entries online, as well as a directory with the sample code.

Cloning repository
https://git.cloud.ibm.com/Organization.Name/webapplication...
Cloning into 'webapplication'...
remote: Counting objects: 60, done.
remote: Compressing objects: 100% (54/54), done.
remote: Total 60 (delta 4), reused 0 (delta 0)
Receiving objects: 100% (60/60), 50.04 KiB | 1.52 MiB/s, done.
Resolving deltas: 100% (4/4), done.
OK

The app, webapplication, has been successfully saved into the
current directory.

That last statement means that if you view your current directory, a new subdirectory webapplication is now visible. This directory holds a scaffold of your new Node.js application. However, while the recipe might be present, the ingredients themselves are still wrapped up in a Docker image and must be combined. Docker is running on your local machine as a consequence of installation, but if you need to restart it do so. If you build your new web application without Docker running it fails, but that's not the only possible error. If you run into trouble, check the resulting error messages, which might have the appropriate link to view result logs in your online portal for your IBM Cloud Platform account.

ibmcloud dev build

Now that the app is built, you can run the code locally with the run command.
Certificate Name The allocated name for the self-signed certificate for database deployment 
 Certificate Base64 A base64 encoded version of the certificate. 





* 0... indicates that there might be one or more of these entries in an array.



Redis drivers are often able to make a connection to your deployment when given the URI-formatted connection string found in the "composed" field of the connection information. For example, if you set the connection string in the environment variable REDIS_URL

export REDIS_URL=rediss://admin:$PASSWORD@e6b2c3f8-54a6-439e-8d8a-aa6c4a78df49.8f7bfd8f3faa4218aec56e069eb46187.databases.appdomain.cloud:32371/0

then the Node.js client is able to make a connection with

let connectionString = process.env.REDIS_URL;

if (connectionString === undefined) {
console.error("Please set the REDIS_URL environment variable");
process.exit(1);
}

let client = null;

client = redis.createClient(connectionString, {
tls: { servername: new URL(connectionString).hostname }
});

Alternatively, the connection string can be parsed and its parts sent to the connection handler, as with the following Python client example

parsed = urlparse(connection_string)

r = redis.StrictRedis(
host=parsed.hostname,
port=parsed.port,
password=parsed.password,
ssl=True,
ssl_ca_certs='/etc/ssl/certs/ca-certificates.crt',
decode_responses=True)

Redis has a vast array of clients for applications to use. A fairly [comprehensive list is maintained on the Redis site](https://redis.io/clients).
A CA is the node that issues certificates to all network participants (peers, ordering services, clients, admins, and so on). These certificates, which include a signing certificate and private key, allow network participants to communicate, authenticate, and ultimately transact. These CAs will create all of the identities and certificates that belong to your organization, in addition to defining the organization itself. You can then use those identities to deploy nodes, create admin identities, and submit transactions. For more information about your CA and the identities that you will need to create, see [Managing identities](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-identitiesibp-console-identities).

In this tutorial, we will create one organization. Therefore, we will need to create one CA.



 Creating your peer organization CA 

Your CA issues the certificates and private keys for your organization's admins, client applications, and nodes. These identities are not managed by IBM and the keys are not stored in the console. They are only stored in your browser local storage. Therefore, make sure to export your identities and the MSP of your organization. If you attempt to access the console from a different machine or a different browser, you will need to import these identities and organization definitions.

Perform the following steps from your console:



1. Navigate to the Nodes tab on the left and click Add Certificate Authority. The side panels will allow you to customize the CA that you want to create and the organization that this CA will issue keys for.
2. In this tutorial, we're creating nodes, so make sure the option to Create a Certificate Authority is selected. Then click Next.
3. Use the side panel to give your CA a display name. Our recommended value for this CA is Org2 CA. Then give your CA admin credentials by specifying a CA administrator enroll ID of admin and a secret of adminpw.
4. The Advanced deployment options are only available in paid clusters and can be safely ignored for purposes of this tutorial. For more information about these options, see the links below.
5. Retrieve the TLS certificate of your CA to be used by the Fabric CA client. If you are using the IBM Blockchain Platform console, open the CA and click Settings, and look for the certificate in base64 format in the TLS Certificate field. If your are using the APIs, you can call GET /ak/api/v2/components]GET _components] and find the CA TLS certificate in the "PEM" field. If you created the CA by using the Create a Fabric CA API, you can also find the TLS certificate in the response body.
You need to convert the certificate from base64 into PEM format to use it to communicate with your CA. Insert the base64 encoded string of the TLS certificate into command below. Ensure that you are in your $HOME/fabric-ca-client directory.

cd $HOME/fabric-ca-client
mkdir catls
export FLAG=$(if "$(uname -s)" == "Linux" ] ! ! ! ! ; then echo "-w 0"; else echo "-b 0"; fi)
echo <base64_string> | base64 --decode $FLAG > tls.pem
<-- </ol> --><-- </section "id="section-ibp-v2-apis-setup-fabric-ca-client" "> --><-- <section "id="section-ibp-v2-apis-enroll-ca-admin" "> --> Generate certificates with your CA admin A CA admin identity was automatically registered for you when you created your CA. You can now use that admin name and password to issue an enroll command with the Fabric CA client to generate an MSP folder with certificates that can then be used to register other peer or ordering node identities.<-- <ol> -->1. Ensure that you complete the steps to set up the Fabric CA client]Set up the Fabric CA client] ! ! ! and that $FABRIC_CA_CLIENT_HOME is set to the directory where you want to store your CA admin certs.
This change to the default runtime will not affect your app if you configured a specific version of Node.js in your app's package.json.

You can always specify the version of Node.js to run your app by using the engines.node entry in your package.json as explained in [Available versions](https://cloud.ibm.com/docs/cloud-foundry-public?topic=cloud-foundry-public-available_versions).





 23 November 2015 

Updated Liberty buildpack v2.2-20151119-1720
: The buildpack contains an updated version of the Liberty profile runtime and WebSphere eXtreme Scale Client with security fixes for the [Apache Commons Collection vulnerability](https://www.ibm.com/blogs/psirt/ibm-security-bulletin-vulnerability-in-apache-commons-affects-liberty-for-java-for-ibm-bluemix-cve-2015-7450/).



* The buildpack also contains an updated version of the [Java MongoDB Driver](https://docs.mongodb.com/drivers/java), v2.13.3. The new driver is compatible with MongoDB version 2.4, 2.6 and 3.0.
* The buildpack also provides an updated version of the data collector for the Monitoring and Analytics service. The updated data collector has improved method tracing capabilities.



Updated Node.js buildpack v2.7-20151118-1003
: With 2.7, version 4.2.1.0 of the IBM SDK for Node.js (based on Node v4.2.1 LTS) is included. It is not the default yet, but can be specified for use. Note: This version replaces the open source build that was previously available. We also made some small bug fixes to our service extension framework.





 22 October 2015 

Updated ASP.NET 5 buildpack v0.7-20151022-1257
: This version of the buildpack removes Mono and instead supports the Beta 8 CoreCLR.





 19 October 2015 

Updated Node.js buildpack v2.6.1-20151015-1326
Go version: go1.13.10
Git commit: 9d988398e7
Built: Fri May 15 00:22:47 2020
OS/Arch: linux/amd64
Experimental: false

 dc --version
dc (GNU bc 1.07.1) 1.4.1

 ed --version
GNU ed 1.14.2
Show more





 Version 3.0 

To view the contents of version 3.0, from the running image, type default_versions.sh. The 3.x branch provides images with the current tool versions. The current Java™ version is Java™ 11. Node.js no longer uses nvm to manage different node.js versions. It provides the current LTS version of Node.js at the time that it was built.

This image includes the following tools:

 node --version
v14.16.1

 npm --version
6.14.12

 jq --version
jq-1.6

 yq --version
yq version 4.6.2

 kubectl version --client
Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.5", GitCommit:"6b1d87acf3c8253c123756b9e61dac642678305f", GitTreeState:"clean", BuildDate:"2021-03-18T01:10:43Z", GoVersion:"go1.15.8", Compiler:"gc", Platform:"linux/amd64"}

 buildctl --version
buildctl github.com/moby/buildkit v0.8.2 9065b18ba4633c75862befca8188de4338d9f94a

 helm version --client
* [Any platform access role](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-perms)
* [The Writer or Manager service access role](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-perms)









 Step 1: Deploy an app and expose it by using an NLB 

The first lesson shows you how your app is exposed from multiple IP addresses and ports, and where public traffic is coming into your cluster.

Start by deploying a sample web server app to use throughout the tutorial. The echoserver web server shows data about the connection that is made to the cluster from the client, and you can test access to the PR firm's cluster. Then, expose the app by creating a network load balancer (NLB) 1.0 service. An NLB 1.0 service makes your app available over both the NLB service IP address and the worker nodes' node ports.

Want to use an Ingress application load balancer (ALB)? Instead of creating an NLB in steps 3 and 4, [create a service for the web server app](https://cloud.ibm.com/docs/containers?topic=containers-managed-ingress-setup) and [create an Ingress resource for the web server app](https://cloud.ibm.com/docs/containers?topic=containers-managed-ingress-setup). Then get the public IPs of your ALBs by running ibmcloud oc ingress alb ls --cluster <cluster_name> and use these IPs throughout the tutorial in place of the <loadbalancer_IP>.

The following image shows how the web server app is exposed to the internet by the public node port and public NLB at the end of Lesson 1.

Zoom

![At the end of Lesson 1, the web server app is exposed to the internet by the public node port and public NLB.]
where <alias> is an alias that you created by using the db2cli writecfg command, <user_id> is your Db2 on Cloud user ID, and <password> is your Db2 on Cloud password.



* To create a connection without SSL, catalog the target Db2 on Cloud database by completing the following steps:



1. Catalog the target Db2 on Cloud node so that client applications can connect to it. Run the following CLP commands:



db2 catalog tcpip node <node_name> remote <IP_address_of_BLUDB_database_server> server <port_number_of_BLUDB_database>

where <node_name> represents your name for the node, <IP_address_of_BLUDB_database_server> represents the IP address of the BLUDB database server, and <port_number_of_BLUDB_database> represents the port number of the BLUDB database.



2. Catalog the remote Db2 on Cloud database so that client applications can connect to it. Run the following command:



db2 catalog db BLUDB as <db_alias> at node <node_name>

where <db_alias> represents your name for the Db2 on Cloud database and <node_name> represents your name for the node.



3. Test the non-SSL connection in one of the following ways:



- Test the connection by using CLP. Issue the following command to connect to the Db2 on Cloud database:

db2 connect to <db_alias> user <user_id>

where <db_alias> is your name for the Db2 on Cloud database and <user_id> is your Db2 on Cloud user ID. You are prompted to enter your password.

db2 list tables

- Test the connection by using CLI. Issue the following command to connect to the Db2 on Cloud database:

db2cli validate -dsn <alias> -connect -user <user_id> -passwd <password>
The Pods, Builds, Services and Routes are visible.

Zoom

![App Details](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution55-openshift-microservices/ocp45-topo-app-details.png)

App Details



* Pods: Your Node.js application containers
* Builds: The auto-generated build that created a Docker image from your Node.js source code, deployed it to the Red Hat OpenShift container registry, and kicked off your deployment config
* Services: Tells Red Hat OpenShift how to access your Pods by grouping them together as a service and defining the port to listen to
* Routes: Exposes your services to the outside world using the LoadBalancer provided by the IBM Cloud network



3. Click on View Logs next to your completed Build. This shows you the process that Red Hat OpenShift took to install the dependencies for your Node.js application and build/push a Docker image. The last entry should looks like this:

Successfully pushed image-registry.openshift-image-registry.svc:5000/example-health/patient-health-frontend@sha256:f9385e010144f36353a74d16b6af10a028c12d005ab4fc0b1437137f6bd9e20a
Push successful
4. Click back to the Topology and select your app again.
5. Click on the URL under Routes to visit your application. Enter any string for username and password, for instance test:test because the app is running in demonstration mode.



The Node.js app has been deployed to Red Hat OpenShift Container Platform. To recap:



* The "Example Health" Node.js application was deployed directly from GitHub into your cluster.
* The application was examined in the Red Hat OpenShift on IBM Cloud console.
Change log for worker node fix pack 1.8.13_1516, released 3 July 2018 



Table 1. Changes since version 1.8.13_1515

 Component Previous Current Description 

 Kernel N/A N/A Optimized sysctl for high performance networking workloads. 







 Change log for worker node fix pack 1.8.13_1515, released 21 June 2018 



Table 1. Changes since version 1.8.13_1514

 Component Previous Current Description 

 Docker N/A N/A For non-encrypted flavors, the secondary disk is cleaned by getting a fresh file system when you reload or update the worker node. 







 Change log 1.8.13_1514, released 19 June 2018 



Table 1. Changes since version 1.8.11_1512

 Component Previous Current Description 

 Kubernetes v1.8.11 v1.8.13 See the [Kubernetes release notes]([https://github.com/kubernetes/kubernetes/releases/tag/v1.8.13](https://github.com/kubernetes/kubernetes/releases/tag/v1.8.13)] 
 Kubernetes Configuration N/A N/A Added PodSecurityPolicy to the --admission-control option for the cluster's Kubernetes API server and configured the cluster to support pod security policies. For more information, see [Configuring pod security policies](https://cloud.ibm.com/docs/containers?topic=containers-psp). 
 IBM Cloud Provider v1.8.11-126 v1.8.13-176 Updated to support Kubernetes 1.8.13 release. 
 OpenVPN client N/A N/A Added livenessProbe to the OpenVPN client vpn deployment that runs in the kube-system namespace. 







 Change log for worker node fix pack 1.8.11_1512, released 11 June 2018 



Table 1. Changes since version 1.8.11_1511

 Component Previous Current Description
You can also access the NLB in each zone by using its public IP address and port on the worker node. Note that by default, each NLB 2.0 is set up in one zone only. To achieve high availability, you must deploy an NLB 2.0 in every zone where you have app instances.
2. A DNS system service resolves the subdomain to the portable public IP address of one of the NLBs and its assigned port on the worker node. In this example, the NLB has a virtual IP address of 169.61.23.130 and runs on the worker node that has the 10.73.13.25 private IP address. Requests are handled by the NLBs in various zones in a round-robin cycle.
3. The NLB encapsulates the client request packet (labeled as "CR" in the image) inside an IPIP packet (labeled as "IPIP"). The client request packet retains the client IP as its source IP address. The IPIP encapsulating packet uses the worker 10.73.14.25 IP as its source IP address.
4. The NLB routes the IPIP packet to a worker that an app pod is on and that has the private IP address 10.73.13.26. Note that each NLB routes requests to the app instances in its own zone and to app instances in other zones. Additionally, if multiple app instances are deployed in one zone, the NLB routes the requests between the app pods in the zone.
5. Worker 10.73.14.26 unpacks the IPIP encapsulating packet, and then unpacks the client request packet. The client request packet is forwarded to the app pod on that worker node.
6. Worker 10.73.14.26 then uses the source IP address from the original request packet, the client IP, to return the app pod's response packet directly to the client.
In this example, the NLB has a virtual IP address of 169.61.23.130 and runs on the worker node that has the 10.73.13.25 private IP address. Note that if you [create a DNS subdomain](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer_hostname) for your NLB, users can access your app through the NLB's subdomain instead. A DNS system service resolves the subdomain to the portable public IP address of the NLB.
2. The NLB encapsulates the client request packet (labeled as "CR" in the image) inside an IPIP packet (labeled as "IPIP"). The client request packet retains the client IP as its source IP address. The IPIP encapsulating packet uses the worker node 10.73.14.25 IP as its source IP address.
3. The NLB routes the IPIP packet to a worker that an app pod is on and that has the private IP address 10.73.13.26. If multiple app instances are deployed in the cluster, the NLB routes the requests between the workers where app pods are deployed.
4. Worker 10.73.14.26 unpacks the IPIP encapsulating packet, and then unpacks the client request packet. The client request packet is forwarded to the app pod on that worker node.
5. Worker 10.73.14.26 then uses the source IP address from the original request packet, the client IP, to return the app pod's response packet directly to the client.







 Traffic flow in a multizone cluster 

The following diagram shows how version 2.0 NLBs in each zone direct traffic from the internet to an app in a multizone cluster.

Zoom

!
MAS-Dedicated Bundles 

The following table shows the distribution of workload across worker nodes. This is based on the T-Shirt sizes on the [Maximo Application Suite Dedicated T-Shirt Calculator v6](https://ibm.box.com/shared/static/aydqzy5in7coc0995vfcctyhg55ic4ar.xlsm) and will be the setup based on the selected size of the sites. For Development and Extra Small, all workloads (UI, MIF, RPT, CRON) go through the same (2) base worker nodes. For Small, Medium and Large, the workloads are distributed through specific worker nodes as per the below table. If a client needs a different configuration, please contact your sales representative.



Table 1. MAS-Dedicated Bundles

 T-Shirt Size Max Concurrent Users Base UI MIF RPT CRON VPC on Order 

 Development 2 4 
 Extra Small 50 2 4 
 Small 100 2 1 1 1 8 
 Medium 250 6 2 2 1 24 
 Large 500 12 3 2 2 48
OpenVPN client and server 2.4.4-r2 2.4.6-r3-IKS-8 Updated image for [CVE-2018-0732](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0732) and [CVE-2018-0737](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0737) 







 Change log for worker node fix 1.9.10_1532, released 7 November 2018 

The following table shows the changes that are in the worker node fix pack 1.9.11_1532.



Table 1. Changes since version 1.9.10_1531

 Component Previous Current Description 

 TPM-enabled kernel N/A N/A Bare metal worker nodes with TPM chips for Trusted Compute use the default Ubuntu kernel until trust is enabled. If you [enable trust](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cli) on an existing cluster, you need to [reload](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_reload) any existing bare metal worker nodes with TPM chips. To check if a bare metal worker node has a TPM chip, review the Trustable field after running the ibmcloud ks flavors --zone[command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_machine_types). 







 Change log for worker node fix pack 1.9.10_1531, released 26 October 2018 

The following table shows the changes that are in the worker node fix pack 1.9.10_1531.



Table 1. Changes since version 1.9.10_1530

 Component Previous Current Description 

 OS interrupt handling N/A N/A Replaced the interrupt request (IRQ) system daemon with a more performant interrupt handler.
Change log for worker node fix pack 1.8.15_1519, released 13 August 2018 



Table 1. Changes since version 1.8.15_1518

 Component Previous Current Description 

 Ubuntu packages N/A N/A Updates to installed Ubuntu packages. 







 Change log for 1.8.15_1518, released 27 July 2018 



Table 1. Changes since version 1.8.13_1516

 Component Previous Current Description 

 IBM Cloud Provider v1.8.13-176 v1.8.15-204 Updated to support Kubernetes 1.8.15 release. In addition, LoadBalancer service create failure events now include any portable subnet errors. 
 IBM Cloud File Storage for Classic plug-in 320 334 Increased the timeout for persistent volume creation from 15 to 30 minutes. Changed the default billing type to hourly. Added mount options to the pre-defined storage classes. In the NFS file storage instance in your IBM Cloud infrastructure account, changed the Notes field to JSON format and added the Kubernetes namespace that the PV is deployed to. To support multizone clusters, added zone and region labels to persistent volumes. 
 Kubernetes v1.8.13 v1.8.15 See the Kubernetes [release notes](https://github.com/kubernetes/kubernetes/releases/tag/v1.8.15) 
 Kernel N/A N/A Minor improvements to worker node network settings for high performance networking workloads. 
 OpenVPN client N/A N/A The OpenVPN client vpn deployment that runs in the kube-system namespace is now managed by the Kubernetes addon-manager. 







 Change log for worker node fix pack 1.8.13_1516, released 3 July 2018 



Table 1. Changes since version 1.8.13_1515

 Component Previous Current Description 

 Kernel N/A N/A Optimized sysctl for high performance networking workloads. 







 Change log for worker node fix pack 1.8.13_1515, released 21 June 2018 



Table 1. Changes since version 1.8.13_1514