vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Set up service-to-service authorization, which allows Security and Compliance Center to communicate with Workload Protection.



1. When you are prompted for service authorization, click Authorize.
2. For the target service, select Workload Protection. Security and Compliance Center is set as the source service. Reader access is automatically selected. Click Review.
3. On the Review page, ensure that the target service and role are correct, and then click Assign.



Alternatively, you can use IAM to create an authorization to allow the Security and Compliance Center service instance access to the Workload Protection service instance.
5. On the Connect your Workload Protection account page, provide a name for your connection.
6. Select the Workload Protection instance, and then click Connect.



After the connection is successfully created, click the Connected tab. If you want to open the Workload Protection instance dashboard, click Dashboard URL.





 Creating the attachment 

To evaluate your resources, you create an attachment. An attachment is the association between the set of resources that you want to evaluate and a profile that contains the specific controls that you want to evaluate. An attachment is how you target a specific grouping of your resources to evaluate against a specific profile.

To create an attachment, complete these steps:



1. In the Security and Compliance Center UI, navigate to the Attachments page, and click Create. A flat list of all of the attachments in your account is displayed.

Alternatively, you can create an attachment through the Profiles page. On the Attachments tab of the profile details page, click Create, and then continue with the next step.
2. Provide a name and description for your attachment. Be as descriptive as possible so that it's easy for other members of your team to understand what is being evaluated. Then, click Next.
3. Select the Profile and Profile version that you want to use for your evaluation.
4. Customize the underlying evaluations in your scan by editing the default parameters to match your specific use case.
5. Define a Scope to identify the resources that you want to evaluate and those that you want to Exclude. Then, click Next.
6.
You can restore data from a snapshot if a user accidentally removes important data from the volume.

Complete the following steps to create a snapshot for your volume.



1. [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).
2. Log in to the ibmcloud sl CLI.

ibmcloud sl init
3. List existing PVs in your cluster.

oc get pv
4. Get the details for the PV for which you want to create snapshot space and note the volume ID, the size and the IOPS. The volume ID, the size and the IOPS can be found in the Labels section of your CLI output.

oc describe pv <pv_name>
5. Create the snapshot size for your existing volume with the parameters that you retrieved in the previous step.

ibmcloud sl file snapshot-order <volume_ID> --size <size> --tier <iops>
6. Wait for the snapshot size to create. The snapshot size is successfully provisioned when the **Snapshot Size (GB)**in your CLI output changes from 0 to the size that you ordered.

ibmcloud sl file volume-detail <volume_ID>
7. Create the snapshot for your volume and note the ID of the snapshot that is created for you.

ibmcloud sl file snapshot-create <volume_ID>
8. Verify that the snapshot is created successfully.

ibmcloud sl file snapshot-list <volume_ID>
9. Set the snapshot schedule. For more information on the options available for your snapshot schedule, refer to the [CLI documentation](https://cloud.ibm.com/docs/cli?topic=cli-sl-block-storagesl_block_snapshot_enable).

ibmcloud sl block snapshot-enable VOLUME_ID <OPTIONS>
10. To restore data from a snapshot to an existing volume, run the following command.
Data LIF dataLIF Config The IP address of the Data LIF. true N/A 
 SVM svm Config The name of the SVM. true N/A 
 User Name username Secret The username to connect to the storage device. true N/A 
 User Password password Secret The password to connect to the storage device. true N/A 
 Export Policy exportPolicy Config The NAS option for the NFS export policy. true default 
 Limit Volume Size limitVolumeSize Config Maximum requestable volume size (in Gibibytes) and qtree parent volume size true 50Gi 
 Limit AggregateUsage limitAggregateUsage Config Fail provisioning if usage is above this percentage. true 80% 
 NFS Mount Options nfsMountOptions Config The NFS mount options. true nfsvers=4 







 22.10 parameter reference 



Table 3. 22.10 parameter reference

 Display name CLI option Type Description Required? Default value 

 Management LIF managementLIF Config The IP address of the Management LIF. true N/A 
 Data LIF dataLIF Config The IP address of the Data LIF. true N/A 
 SVM svm Config The name of the SVM. true N/A 
 User Name username Secret The username to connect to the storage device. true N/A 
 User Password password Secret The password to connect to the storage device. true N/A 
 Export Policy exportPolicy Config The NAS option for the NFS export policy. true default 
 Limit Volume Size limitVolumeSize Config Maximum requestable volume size (in Gibibytes) and qtree parent volume size true 50Gi 
 Limit AggregateUsage limitAggregateUsage Config Fail provisioning if usage is above this percentage. true 80% 
 NFS Mount Options nfsMountOptions Config The NFS mount options. true nfsvers=4 









 Storage class reference for NetApp ONTAP-NAS
The block size that is used by your application directly impacts the storage performance. If the block size that is used by your application is smaller than 16 KB, the IOPS limit is realized before the throughput limit. Conversely, if the block size that is used by your application is larger than 16 KB, the throughput limit is realized before the IOPS limit.



Table 1 shows examples of how block size and IOPS affect the throughput. Average IO size x IOPS = Throughput in MB/s.

 Block Size (KB) IOPS Throughput (MB/s) 

 4 1,000 4 
 8 1,000 8 
 16 1,000 16 
 32 500 16 
 64 250 16 
 128 128 16 
 512 32 16 
 1024 16 16 







 Authorized hosts 

Another factor to consider is the number of hosts that are using your volume. If only a single host is accessing the volume, it can be difficult to realize the maximum IOPS available, especially at extreme IOPS counts (10,000s). If your workload requires high throughput, it would be best to configure at least a couple servers to access your volume to avoid a single-server bottleneck.





 Network connection 

The speed of your Ethernet connection must be faster than the expected maximum throughput from your volume. Generally, don't expect to saturate your Ethernet connection beyond 70% of the available bandwidth. For example, if you have 6,000 IOPS and are using a 16-KB block size, the volume can handle approximately 94-MBps throughput. If you have a 1-Gbps Ethernet connection to your LUN, it becomes a bottleneck when your servers attempt to use the maximum available throughput. It's because 70 percent of the theoretical limit of a 1-Gbps Ethernet connection (125 MB per second) would allow for 88 MB per second only.

To achieve maximum IOPS, adequate network resources need to be in place. Other considerations include private network usage outside of storage, and host side and application-specific tunings (IP stack or [queue depths](https://cloud.ibm.com/docs/BlockStorage?topic=BlockStorage-hostqueuesettings), and other settings).
[The Truck Tracker Zoom View](https://cloud.ibm.com/docs-content/v1/content/ec83e0c9f915f4acf715222aaa5b8387c028200c/databases-for-mongodb/includes/cloud-databases/includes/cloud-databases/images/trucktrackerzoom.png)

Figure 4. Single-Truck View







 What you just did 



 The build.sh script 

The build.sh script does a number of things:



1. It builds a docker image for each of the services you need. The producer, consumers and web application are all in different folders. Each folder has its own simple Dockerfile file that is used by the script to create a container image, which is then uploaded to the IBM Container Registry.
2. It creates a bunch of kubernetes secrets with all the credentials that are going to be needed to access the different IBM services (IBM Cloudant, Redis and Event Streams).
3. It deploys the application code (and the secretes) to the Red Hat OpenShift on IBM Cloud cluster using the instructions contained in the deployment.yml script.







 The deployment.yml script 

This script tells Openshift what to deploy to the machines in the Openshift cluster. In our case this is:



1. Data producers (trucktrackerproducer).
2. Data consumers (trucktrackerredisconsumer and trucktrackercloudantconsumer)
3. Web application (trucktrackerweb)



In all cases, they pull an image from the container registry and get fed some environment variables with the credentials they require to access external services.





 The Truck Tracker system 

The Truck Tracker system is a set of simple Node.js scripts that use four main packages:



1. [@ibm-cloud/cloudant](https://github.com/IBM/cloudant-node-sdk) to connect to IBM Cloudant and read/write data.
2.
[The Truck Tracker Zoom View](https://cloud.ibm.com/docs-content/v1/content/c1b02d6157702384a9668d8c58bb951e69117793/databases-for-redis/includes/cloud-databases/includes/cloud-databases/images/trucktrackerzoom.png)

Figure 4. Single-Truck View







 What you just did 



 The build.sh script 

The build.sh script does a number of things:



1. It builds a docker image for each of the services you need. The producer, consumers and web application are all in different folders. Each folder has its own simple Dockerfile file that is used by the script to create a container image, which is then uploaded to the IBM Container Registry.
2. It creates a bunch of kubernetes secrets with all the credentials that are going to be needed to access the different IBM services (IBM Cloudant, Redis and Event Streams).
3. It deploys the application code (and the secretes) to the Red Hat OpenShift on IBM Cloud cluster using the instructions contained in the deployment.yml script.







 The deployment.yml script 

This script tells Openshift what to deploy to the machines in the Openshift cluster. In our case this is:



1. Data producers (trucktrackerproducer).
2. Data consumers (trucktrackerredisconsumer and trucktrackercloudantconsumer)
3. Web application (trucktrackerweb)



In all cases, they pull an image from the container registry and get fed some environment variables with the credentials they require to access external services.





 The Truck Tracker system 

The Truck Tracker system is a set of simple Node.js scripts that use four main packages:



1. [@ibm-cloud/cloudant](https://github.com/IBM/cloudant-node-sdk) to connect to IBM Cloudant and read/write data.
2.
Retrieve the StorageType, volumeId, and the server of the physical File Storage for Classic that is associated with your PVC by listing the details of the PV that your PVC is bound to. Replace <pv_name> with the name of the PV that you retrieved in the previous step. The storage type, volume ID, and the server name are shown in the Labels section of your CLI output.

oc describe pv <pv_name>

Example output

Name: pvc-4b62c704-5f77-11e8-8a75-b229c11ba64a
Labels: CapacityGb=20
Datacenter=dal10
Iops=2
StorageType=ENDURANCE
Username=IBM02SEV1543159_6
billingType=hourly
failure-domain.beta.kubernetes.io/region=us-south
failure-domain.beta.kubernetes.io/zone=dal10
path=IBM01SEV1234567_8ab12t
server=fsf-dal1001g-fz.adn.networklayer.com
volumeId=12345678
...
3. Modify the size or IOPS of your volume in your IBM Cloud infrastructure account.

Example for performance storage.

ibmcloud sl file volume-modify <volume_ID> --new-size <size> --new-iops <iops>

Example for endurance storage.

ibmcloud sl file volume-modify <volume_ID> --new-size <size> --new-tier <iops>

volume_ID
: Enter the ID of the volume that you retrieved earlier.

new-size
: Enter the new size in gigabytes (Gi) for your volume. For valid sizes, see [Deciding on the File Storage for Classic configuration](https://cloud.ibm.com/docs/openshift?topic=openshift-file_storagefile_predefined_storageclass). The size that you enter must be greater than or equal to the current size of your volume.
[https://www.ibm.com/support/pages/integrity-checker-sequence-not-setup-correctly](https://www.ibm.com/support/pages/integrity-checker-sequence-not-setup-correctly)







 Initial Set Up 

The initial set up includes several components including:

Creation of the target MAS SaaS environment Identification of all components that need to be migrated (database, code, attachments) Final documentation of the integration's and any initial set-up that can be done (including VPN's).

The goal of this step is to ensure all components are in place so the first test can begin.



Table 1. Initial Setup Responsibilities

 Task IBM Client (or Designate) 

 Deploy MAS in selected data center X 
 Install Applications X 
 Perform initial configuration X 
 Identify SaaS Flex site for data to use in initial test X 
 Identify all components that need to be migrated (attachments, custom reports) X 
 Begin VPN Set up (optional) X X 
 Remediation of JAVA class files to Automation Script(s) X 
 Configure any integrations in MAS X 







 Test 1 

Test 1 executes all of the steps required to move a customer from the SaaS Flex (or on-premise) implementation to the MAS SaaS offering. Data is exported from the source system, transferred to the MAS-SaaS location and loaded into the new database instance. Configuration is completed for integration's and any technical remediation performed for the technology differences. Next the client tests to ensure all business flows are performing as expected. Issues identified are then resolved until the testing is complete.



Table 1. Test 1 Responsibilities

 Task IBM Client (or Designate) 

 Export data from SaaS Flex and transfer to MAS-SaaS X 
 Remediate technical changes in MAS through Maxadmin X 
 Remediate technical changes in MAS at OS Level X 
 Deploy Attachments X 
 Import Database X 
 Finalize any changes needed X 
 Ensure any integrations X 
 Test Changes X 
 Remediate errors Secondary Primary 







 Test 2 

This is similar to test 1, except the focus is ensuring all steps are documented and accurate timings taken for the final migration of production.
Options are: 0.25,2,4,10.

-d, --datacenter
: Required. Data center short name.

-n, --snapshot-size
: Optional parameter for ordering snapshot space along with the volume.

-b, --billing
: Optional parameter for Billing rate (default to monthly), options are: hourly, monthly.

-f, --force
: Force operation without confirmation.

Examples:

ibmcloud sl file volume-order --storage-type performance --size 1000 --iops 4000 -d dal09

This command orders a performance volume with size is 1000 GB, IOPS is 4000, and in data center dal09.





 ibmcloud sl file volume-modify 

Modify an existing file storage volume:

ibmcloud sl file volume-modify VOLUME_ID [OPTIONS]

Command options:

-c, --new-size
: New Size of file volume in GB. If no size is given, the original size of volume is used. Potential Sizes: [20, 40, 80, 100, 250, 500, 1000, 2000, 4000, 8000, 12000] Minimum: [the original size of the volume]

-i, --new-iops
: Performance Storage IOPS. Range [100-6000], and in multiples of 100 [only for performance volumes]. If no IOPS value is specified, the original IOPS value of the volume is used. Requirements: [If original IOPS/GB for the volume is less than 0.3, new IOPS/GB must also be less than 0.3. If original IOPS/GB for the volume is greater than or equal to 0.3, new IOPS/GB for the volume must also be greater than or equal to 0.3.]

-t, --new-tier
: Endurance Storage Tier (IOPS per GB) [only for endurance volumes]. If no tier is specified, the original tier of the volume is used. Requirements: [If original IOPS/GB for the volume is 0.25, new IOPS/GB for the volume must also be 0.25.
Configuring Discovery 

Configuring Discovery makes it possible to gain useful insights by enriching your own data and then delivering it in a query-able form.

Before you add your own content to Discovery, you must configure the basic parameters of the service ([Preparing the service for your documents](https://cloud.ibm.com/docs/discovery?topic=discovery-configservicepreparing-the-service-for-your-documents)). This includes creating an environment and creating one or more collections within that environment.



 Preparing the service for your documents 

In Discovery, the content that you upload is stored in a collection that is part of your environment. You must create the environment and collection before you can upload your content.



* Environment — The environment defines the amount of storage space that you have for content in Discovery. A maximum of one environment can be created for each instance of Discovery.

You have several plans (Lite, Advanced, Premium) to choose from, see the [Discovery catalog](https://cloud.ibm.com/catalog/services/discovery) and [Discovery Pricing Plans](https://cloud.ibm.com/docs/discovery?topic=discovery-discovery-pricing-plans) for details. Your source files do not count against your plan size limit, only the size of the converted JSON that is indexed counts towards your size limit.
* Collection — A collection is a grouping of your content within the environment. You must create at least one collection to be able to upload your content.

Collections are comprised of your private data, but Discovery also includes Discovery News, a pre-enriched, public dataset.

Discovery News, a public data set that is pre-enriched with cognitive insights, is also included with Discovery. You can use it to query for insights; for example: news alerts, event detecting, and trending topics in the news; that you can integrate into your applications. See [Watson Discovery News](https://cloud.ibm.com/docs/discovery?topic=discovery-watson-discovery-news) for more information. You cannot adjust the Discovery News configuration or add documents to this collection.
[https://www.ibm.com/support/pages/integrity-checker-sequence-not-setup-correctly](https://www.ibm.com/support/pages/integrity-checker-sequence-not-setup-correctly)







 Initial Set Up 

The initial set up includes several components including:



* Creation of the target MAS Dedicated environment
* Identification of all components that need to be migrated (database, code, attachments)
* Final documentation of the integration's and any initial set-up that can be done (including VPN's)



The goal of this step is to ensure all components are in place so the first test can begin.



Table 1. Initial Setup Responsibilities

 Task IBM Client (or Designate) 

 Deploy MAS in selected data center X 
 Install Applications X 
 Perform initial configuration X 
 Identify SaaS Flex site for data to use in initial test X 
 Identify all components that need to be migrated (attachments, custom reports) X 
 Begin VPN Set up (optional) X X 
 Remediation of JAVA class files to Automation Script(s) X 
 Configure any integrations in MAS X 







 Test 1 

Test 1 executes all of the steps required to move a customer from the SaaS Flex (or on-premise) implementation to the MAS Dedicated offering. Data is exported from the source system, transferred to the Dedicated Service location and loaded into the new database instance. Configuration is completed for integration's and any technical remediation performed for the technology differences. Next the client tests to ensure all business flows are performing as expected. Issues identified are then resolved until the testing is complete.



Table 1. Test 1 Responsibilities

 Task IBM Client (or Designate) 

 Export data from SaaS Flex and transfer to MAS X 
 Remediate technical changes in MAS through Maxadmin X 
 Remediate technical changes in MAS at OS Level X 
 Deploy Attachments X 
 Import Database X 
 Finalize any changes needed X 
 Ensure any integrations X 
 Test Changes X 
 Remediate errors Secondary Primary 







 Test 2 

This is similar to test 1, except the focus is ensuring all steps are documented and accurate timings taken for the final migration of production.
--annotation-fileFILE, -AFILE
: A JSON file that contains annotation in a KEYVALUE format. This flag is optional.

ACTION_NAME
: The name of the action. To include the action in a package, enter the name in the format PACKAGE_NAME/ACTION_NAME. This value is required.

APP_FILE
: The path to the app file or package to run as an action. This option is required when you want to update your app within the action.

--copy
: Treat the action as the name of an existing action.

--docker DOCKER_HUB_USERNAME/IMAGE_NAME
: The Docker Hub user name and the name of the Docker image in Docker Hub to run the action. This flag is required for creating actions from Docker images.

--kind LANGUAGE
: The runtime for your app. This flag is optional. If no VALUE is specified, the default version for the detected runtime is used. Possible values for the --kind option. | Language | Kind identifier | | ---- | -------------- | | Node.js | nodejs:16 (default) | | Python | python:3.11 (default) | | PHP | php:8.1 (default) | | Go | go:1.19 (default) | | Ruby | ruby:2.6 (default) | | Java | java (JDK 8) (default) | | .NET Core | dotnet:2.2 (default) |

Other languages are supported by using Docker actions.

--logsizeLIMIT, -lLIMIT
: The maximum log size in MB for the action. The default value is 10 MB.

--main ENTRY_METHOD_NAME
: If the action's entry method is not main, specify the custom name. This flag is required when the entry method is not main. For some runtimes, such as Java, the name must be the fully qualified method.

--memory MEMORY_LIMIT
: The maximum memory limit in MB for your action.
Configuring data events through the IBM Cloud UI 

You can change what types of events are sent to IBM Cloud Activity Tracker in the IBM Cloud Dashboard by following these steps:



1. Go to the Resource list, and select an IBM Cloudant instance.

The Manage page opens.
2. Click Overview. The Deployment Details pane opens.
3. Find Activity Tracker event types in the list.
4. Select the appropriate type, either Management or Management & Data, from the drop-down menu.
5. Click Save.







 Configuring data events by using the IBM Cloudant API 

You can use the IBM Cloudant API to manage the configuration of Activity Tracker events.

The API to view and change the event types requires IBM Identity and Access Management (IAM) authentication. The use of IBM Cloudant legacy authentication isn't supported for this API endpoint. See [Managing access](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-managing-access-for-cloudant) for details on using IAM authentication for IBM Cloudant.



 Check what event types are configured for an IBM Cloudant instance 

The /_api/v2/user/activity_tracker/events endpoint returns a types field in the response that includes an array of event types that are being sent to IBM Cloud Activity Tracker for the IBM Cloudant instance.

See the following example request to retrieve information about configured event types by using HTTP:

GET $SERVICE_URL/_api/v2/user/activity_tracker/events

Before you run a curl request, run the following command from the command line to acquire a JWT token: ibmcloud iam oauth-tokens | awk '{print $4}'

See the following example request to retrieve information about event types:



* Curl
* Java
* Node
* Python
* Go



curl -H "Authorization: Bearer $JWT" -X GET "$SERVICE_URL/_api/v2/user/activity_tracker/events"

import com.ibm.cloud.cloudant.v1.Cloudant;