vania-janet/multiturn-rag-retrieval-data huggingface dataset:
You can customize by following the steps to [edit the default configuration](https://cloud.ibm.com/docs/schematics?topic=schematics-configure-k8s-clusteredit-agent-namespace-confg).





 Editing the agent namespace configurations 

You can follow these steps to edit the default configuration of an agent namespace.



1. Log in to [IBM Cloud](https://cloud.ibm.com/).
2. Click Kubernetes from the left hand navigator pane, then click Clusters
3. On the Kubernetes Clusters page, click your cluster > Kubernetes dashboard.



* Click the default drop down to view the list of Namespaces:



* In the drop down, type the Schematics-runtime Namespaces to view the Workload Status, Deployments, Pods, Replica sets, and so on.
* From the Deployments panel. Click the three dots against runtime-ansible-job.
* Click Edit to view the Edit a resource page with the YAML, and JSON tabs.
* You can now view the parameters and reconfigure to customize your agent configuration.
* Click Update to apply your edits.
* Restart the deployment and check if all the pods are in running state.





4. Similarly, you can edit the configuration for all the agent namespaces to customize.
Under the Dashboards section, select Kubernetes > Pod Status & Performance to view raw metrics for all workloads running on the cluster.
2. Set the namespace filter to example-health to focus on the pods of your application.
3. Under Dashboards on the left pane, expand Applications in Dashboard Templates. Then select HTTP to get a global view of the cluster HTTP load.







 Explore the cluster and the node capacity 



1. Select Dashboards, check out the two dashboard templates:



* Containers > Container Resource Usage
* Host Infrastructure > Host Resource Usage



2. Select the Pod Rightsizing & Workload Capacity Optimization template. This dashboard helps you to optimize your infrastructure and better control cluster spend by ensure pods are sized correctly. Understand if you can free up resources by reducing memory and/or CPU requests.







 Explore the Network 



1. Select Dashboards and the template Host Infrastructure > Network.

The following dashboard is displayed. It shows information about all resources that are monitored through the instance.

Zoom

![Network](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution55-openshift-microservices/dashboard-img-2.png)

Network
2. Create a customized dashboard and then scope it to a specific namespace.



* In the action menu in the upper right click Create Custom Dashboard and name it Yourname Network
* Click Create and Open.
* Edit the dashboard scope.
* Set the filter to kube.namespace.name, is, ibm-observe.

Zoom

![Configure Filter](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution55-openshift-microservices/explore-img-10.png)
kubectl get pods --all-namespaces -o=jsonpath='{range .items[]}{"n"}{.metadata.name}{":t"}{range .spec.volumes[]}{.persistentVolumeClaim.claimName}{" "}{end}{end}' | grep "<pvc_name>"
* [Retrieve your IBM Cloud Object Storage service credentials, the bucket name, and the bucket hostname](https://cloud.ibm.com/docs/containers?topic=containers-utilitiesbackup_restore_setup_object_storage).
* [Follow the instructions](https://cloud.ibm.com/docs/containers?topic=containers-helminstall_v3) to install the Helm client on your local machine and set up the IBM Cloud Helm chart repositories.
* [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)



You can deploy the ibm-storage-backup pod or the ibm-storage-restore pod by either editing and applying the values.yaml file of the Helm chart, or by running the helm install command from the CLI.

To back up or restore a PVC by editing the values.yaml file:



1. Download the latest Helm chart version to your local machine.

helm fetch --untar iks-charts/ibmcloud-backup-restore
2. Open the values.yaml file in the nano command line editor.

nano ibmcloud-backup-restore/values.yaml
3. Configure your Helm chart to back up or restore PVC data. You can configure the backup for more than one PVC.

Example to create a backup pod by configuring the values.yaml file:

image:
repository: icr.io/iks-charts/ibmcloud-backup-restore
pullPolicy: Always
tag: latest
So in the example above the value of the namespace is nf85a2a.

Find the smart contract pod

Next, get a list of all of the smart contract pods running in your cluster:

kubectl get po -n <NAMESPACE> | grep chaincode-execution | cut -d" " -f1 | xargs -I {} kubectl get po {} -n <NAMESPACE> --show-labels

Replacing <NAMESPACE> with the name of your cluster namespace.

You should see results similar to:

NAME READY STATUS RESTARTS AGE LABELS
chaincode-execution-0a8fb504-78e2-4d50-a614-e95fb7e7c8f4 1/1 Running 0 14s chaincode-id=javacc-1.1,peer-id=org1peer1
NAME READY STATUS RESTARTS AGE LABELS
chaincode-execution-f3cc736f-94ef-454d-8da3-362a50c653d9 1/1 Running 0 4m chaincode-id=nodecc-1.1,peer-id=org1peer1

Your smart contract name and version is visible next to the chaincode-id.

View the logs

Then, to view the logs for a specific smart contract pod, run the command:

kubectl logs -f <SMART_CONTRACT_POD> -n <NAMESPACE>

Replace



* <SMART_CONTRACT_POD> with the name of the pod where the smart contract is running.
* <NAMESPACE> with the name of your cluster namespace.



For example:

kubectl logs -f chaincode-execution-0a8fb504-78e2-4d50-a614-e95fb7e7c8f4 -n nf85a2a





 Hyperledger Fabric v1.4 peer image 

!
Create an authentication policy file that is named default.yaml. This policy is namespace-scoped and configures workloads in the service mesh to accept only encrypted requests with TLS. Note that no targets specifications are included because the policy applies to all services in the mesh in this namespace.

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
name: "default"
spec:
mtls:
mode: STRICT
2. Apply the authentication policy to a namespace.

kubectl apply -f default.yaml -n <namespace>
3. Create a destination rule file that is named destination-mtls.yaml. This policy configures service mesh workloads in a namespace to send traffic by using TLS. Note that the host: .local wildcard applies this destination rule to all services in the mesh.

apiVersion: "networking.istio.io/v1beta1"
kind: "DestinationRule"
metadata:
name: "destination-mtls"
spec:
host: ".local"
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
4. Apply the destination rule.

kubectl apply -f destination-mtls.yaml -n <namespace>
5. If you want to achieve mTLS for service mesh workloads in other namespaces, repeat these steps each namespace.



Destination rules are also used for non-authentication reasons, such as routing traffic to different versions of a service. Any destination rule that you create for a service must also contain the same TLS block that is set to mode: ISTIO_MUTUAL. This block prevents the rule from overriding the mesh-wide mTLS settings that you configured in this section.
workspace_name Optional Enter a name for your workspace. The maximum length of character limit is set to less than 1 MB. For more information, see [Designing your workspace structure](https://cloud.ibm.com/docs/schematics?topic=schematics-workspaces-planstructure-workspace). 
 terraform_version Optional The Terraform version that you want to use to run your Terraform code. Enter terraform_v1.1 to use Terraform version 1.1,terraform_v1.0 to use Terraform version 1.0, and similarly, terraform_v0.15, terraform_v0.14, terraform_v0.13, terraform_v0.12. For example, when you specify terraform_v1.1 means users can have template that are of Terraform v1.1.0, v1.1.1, or v1.1.2, so on. Make sure that your Terraform config files are compatible with the Terraform version that you specify. This is a required variable. If the Terraform version is not specified, By default, Schematics selects the version from your template. Schematics supports Terraform_v1.x and also plans to make releases available after 30 to 45 days of HashiCorp Configuration Language (HCL) release. 
 location Optional Enter the location where you want to create your workspace. The location determines where your Schematics Actions run and where your workspace data is stored. If you do not enter a location, Schematics determines the location based on the IBM Cloud region that you targeted. To view the region that you targeted, run ibmcloud target --output json and look at the region field. To target a different region, run ibmcloud target -r <region>. If you enter a location, make sure that the location matches the IBM Cloud region that you targeted. 
 description Optional Enter a description for your workspace. 
 template_repo.url Optional Enter the URL to the GitHub or GitLab repository where your Terraform configuration files are stored.
name: mirror-bucket-class
namespace: openshift-storage
spec:
placementPolicy:
tiers:
- backingStores:
- backing-store-one
- backing-store-two
placement: Mirror







 Creating a storage class 

After you create backing stores and a bucket class, create a storage class to make your bucket class resources available across the namespaces in your cluster.



1. Create a storage class YAML file that contains a name for your storage class in the format <name>-noobaa.noobaa.io, the name of the bucket class that you want to use, and the provisioner set to openshift-storage.noobaa.io/obc.

metadata:
name: <name>-noobaa.noobaa.io
parameters:
bucketclass: <bucket-class-name>
provisioner: openshift-storage.noobaa.io/obc
reclaimPolicy: Delete
volumeBindingMode: Immediate
2. Create the storage class in your cluster.

oc create -f sc.yaml
3. Verify the storage class is created.

oc get sc







 Creating an Object Bucket Claim 

After you create backing stores and a bucket class, you can create an object bucket claim that you can use to claim storage resources for your s3 apps.



1. Create an object bucket claim YAML file that references the bucket class that you created earlier.

apiVersion: objectbucket.io/v1alpha1
kind: ObjectBucketClaim
metadata:
name: cos-obc
spec:
storageClassName: cos-noobaa.noobaa.io
bucketName: cos-bucket
2. Create the object bucket claim in your cluster.

oc apply -f obc.yaml
3. Verify the OBC is created.

noobaa obc list
4. List the secrets and config maps in your cluster and verify that the corresponding secret and config map for your OBC are created.
You can also choose to [pre-provision your PVCs or use existing PVCs](https://cloud.ibm.com/docs/openshift?topic=openshift-block_storageblock_static_statefulset) with your stateful set.



 Creating the PVC by using dynamic provisioning when you create a stateful set 

Use this option if you want to automatically create the PVC when you create the stateful set.

Before you begin: [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).

Complete the following steps to verify that all existing stateful sets in your cluster are fully deployed. If a stateful set is still being deployed, you can't start creating your stateful set. You must wait until all stateful sets in your cluster are fully deployed to avoid unexpected results.



1. List existing stateful sets in your cluster.

oc get statefulset --all-namespaces

Example output

NAME DESIRED CURRENT AGE
mystatefulset 3 3 6s
2. View the Pods Status of each stateful set to ensure that the deployment of the stateful set is finished.

oc describe statefulset <statefulset_name>

Example output

Name: nginx
Namespace: default
CreationTimestamp: Fri, 05 Oct 2022 13:22:41 -0400
Selector: app=nginx,billingType=hourly,region=us-south,zone=dal10
Labels: app=nginx
billingType=hourly
region=us-south
zone=dal10
Annotations: oc.kubernetes.io/last-applied-configuration={"apiVersion":"apps/v1","kind":"StatefulSet","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"spec":{"podManagementPolicy":"Par..."
Replicas: 3 desired | 3 total
<SECRET_NAME> is the name of the secret.

<INGESTION_URL> indicates the ingestion endpoint. You must set this value to the ingestion endpoint for the region where the Monitoring instance is available.

For Prometheus version 2.26 and later versions, follow these instructions:

Edit the configMap:

kubectl edit cm <PROMETHEUS_CONFIG_MAP> -n <PROMETHEUS_NAMESPACE>

Add the remote_write section:

prometheus.yml: 
global:
evaluation_interval: 1m
scrape_interval: 1m
scrape_timeout: 10s
scrape_configs:
- job_name: ...
remote_write:
- url: https://<INGESTION_URL>/prometheus/remote/write
authorization:
credentials_file: /etc/secrets/<SECRET_NAME>

Where

<SECRET_NAME> is the name of the secret.

<INGESTION_URL> indicates the ingestion endpoint. You must set this value to the ingestion endpoint for the region where the Monitoring instance is available.
3. Manage the metrics that you want to collect and send to the Monitoring instance.

To select which series and labels to collect, and reduce the number of active series that are sent to the Monitoring instance, you can set up relabel configurations by using the write_relabel_configs block within your remote_write section.

For example, to collect metrics from the namespace my-namespace, you can add the following:

remote_write:
- url: https://<INGESTION_URL>/prometheus/remote/write
authorization:
credentials_file: /etc/secrets/<SECRET_NAME>
write_relabel_configs:
- action: keep
regex: my-namespace
source_labels:
- namespace
4. Restart your Prometheus server to reload the configuration.

For example, you can delete the pod to force a restart.
"name": "<workspace_name>",
"type": "<terraform_version>",
"description": "<workspace_description>",
"tags": [],
"resource_group": "<resource_group>",
"workspace_status": {
"frozen": "<true_or_false>"
},
"template_repo": {
"url": "<source_repo_url>"
},
"template_data": [
{
"folder": ".",
"type": "<terraform_version>",
"env_values":
{
"VAR1":"<val1>"
},
{
"VAR2":"<val2>"
}
],
"variablestore":
{
"name": "<variable_name1>",
"value": "<variable_value1>",
"type": "<variable_type1>",
"secure": true,
"use_default": true },
{
"name": "<variable_name2>",
"value": "<variable_value2>",
"type": "<variable_type2>",
"secure": false,
"use_default": true
}
]
}
],
}
Show more



IBM Cloud Schematics update payload

 Parameter Required / Optional Description 

 name Optional Enter a name for your workspace. For more information, see [Designing your workspace structure](https://cloud.ibm.com/docs/schematics?topic=schematics-workspace-setupstructure-workspace). If you update the name of the workspace, the ID of the workspace does not change. 
 type Optional The Terraform version that you want to use to run your Terraform code.
2. Apply the authentication policy to a namespace.

kubectl apply -f default.yaml -n <namespace>
3. Create a destination rule file that is named destination-mtls.yaml. This policy configures service mesh workloads in a namespace to send traffic by using TLS. Note that the host: .local wildcard applies this destination rule to all services in the mesh.

apiVersion: "networking.istio.io/v1beta1"
kind: "DestinationRule"
metadata:
name: "destination-mtls"
spec:
host: ".local"
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
4. Apply the destination rule.

kubectl apply -f destination-mtls.yaml -n <namespace>
5. If you want to achieve mTLS for service mesh workloads in other namespaces, repeat these steps each namespace.



Destination rules are also used for non-authentication reasons, such as routing traffic to different versions of a service. Any destination rule that you create for a service must also contain the same TLS block that is set to mode: ISTIO_MUTUAL. This block prevents the rule from overriding the mesh-wide mTLS settings that you configured in this section.
If you choose incremental, you must specify the SCHEDULING_INFO and SCHEDULING_TYPE option. If you don't specify the BACKUP_TYPE option, a full backup is created by default.

SCHEDULE_TYPE
: Required only for backups. Enter periodic to create scheduled backups, or leave this option empty to create a one-time backup. If you want to create periodic backups, you must define the backup interval in the SCHEDULE_INFO option.

SCHEDULE_INFO
: Required only for backups. If you want to create periodic backups, you must decide on the backup schedule. Choose between hourly, daily, or weekly. If you set this option, you must set SCHEDULE_TYPE to periodic.
4. Save and close the values.yaml file.
5. Install the Helm chart with your custom settings in the values.yaml file. When you install the Helm chart and you configure a backup or restore, an ibm-storage-backup or an ibm-storage-restore pod is deployed to your cluster. The backup pod backs up the data from your PVC to IBM Cloud Object Storage and the restore pod restores data to a PVC. Replace <release_name> with a name for your Helm chart. Be sure to install the backup and restore pods in the same zone as the PVC that you want to back up or restore.



* Install the Helm chart by using the helm install command.

helm install <release_name> ./ibmcloud-backup-restore -n <namespace>

Example output for backup:

NAME: <release_name>
LAST DEPLOYED: Mon Jan 20 09:17:02 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Thank you for installing: ibmcloud-backup-restore. Your release is named: <release_name>

Please refer Chart README.md file for creating a sample PVC
Please refer Chart RELEASE.md to see the release details/fixes
* Optional: Install the Helm chart by setting options in the helm install command. You can name your release by specifying the --name parameter.
Follow the steps in [Adding Block Storage for VPC to your apps](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-blockvpc-block-add) to create a PVC with your custom settings. Make sure to create the PVC with the customized storage class that the cluster admin created and use the same name for your PVC that you used for your secret. Using the same name for the secret and the PVC triggers the storage provider to apply the settings of the secret in your PVC.







 Enforcing base64 encoding for the Key Protect root key CRN 



1. As the cluster admin, create a Kubernetes secret that includes the base64 encoded value for your Key Protect root key CRN. To retrieve the root key CRN, see [Setting up encryption for your Block Storage for VPC](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-blockvpc-block-encryption).

apiVersion: v1
kind: Secret
type: vpc.block.csi.ibm.io
metadata:
name: <secret_name>
namespace: <namespace_name>
stringData:
encrypted: <true_or_false>
resourceGroup: "<resource_group>"
data:
encryptionKey: <encryption_key>

name
: Enter a name for your Kubernetes secret.

namespace
: Enter the namespace where you want to create your secret. To reference the secret in your PVC, the PVC must be created in the same namespace.

encrypted
: In the string data section, enter true to create a secret that sets up encryption for Block Storage for Classic volumes. If you set this option to true, you must provide the root key CRN of your Key Protect service instance that you want to use in parameters.encryptionKey.
If a namespace or action is not specified, the space is polled.

ACTION_NAME
: An action name. Poll activations for a namespace, an action, or a space. This value is optional. If a namespace or action is not specified, the space is polled.

--exitSECONDS, -eSECONDS
: Poll activations for a specified number of seconds and then exit. This flag is optional.

--since-daysDAYS
: Start polling for activations a specified number of days ago. This flag is optional.

--since-hoursHOURS
: Start polling for activations a specified number of hours ago. This flag is optional.

--since-minutesMINUTES
: Start polling for activations a specified number of minutes ago. This flag is optional.

--since-secondsSECONDS
: Start polling for activations a specified number of seconds ago. This flag is optional.





 Example 

ibmcloud fn activation poll







 ibmcloud fn activation result 

Get the result from a specific activation.

ibmcloud fn activation result [ACTIVATION_ID] [--last] [--strip]



 Command options 

ACTIVATION_ID
: The ID for a specific activation. Use ibmcloud fn activation list to retrieve a list of available IDs. This value is required, unless the --last or -l option is specified.

--last, -l
: Display the result for the most recent activation. This flag is optional.





 Example 

ibmcloud fn activation result 8694a4501be6486a94a4501be6886a1e









 Deployment commands 

Use deployment commands to deploy and undeploy packages, actions, triggers, and rules.



 ibmcloud fn deploy 

Use a manifest file to deploy a collection of packages, actions, triggers, and rules.

To see CLI help for the deploy command, run ibmcloud fn deploy.
oc get pods --all-namespaces -o=jsonpath='{range .items[]}{"n"}{.metadata.name}{":t"}{range .spec.volumes[]}{.persistentVolumeClaim.claimName}{" "}{end}{end}' | grep "<pvc_name>"
* [Retrieve your IBM Cloud Object Storage service credentials, the bucket name, and the bucket hostname](https://cloud.ibm.com/docs/openshift?topic=openshift-utilitiesbackup_restore_setup_object_storage).
* [Follow the instructions](https://cloud.ibm.com/docs/openshift?topic=openshift-helminstall_v3) to install the Helm client on your local machine and set up the IBM Cloud Helm chart repositories.
* [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).



You can deploy the ibm-storage-backup pod or the ibm-storage-restore pod by either editing and applying the values.yaml file of the Helm chart, or by running the helm install command from the CLI.

To back up or restore a PVC by editing the values.yaml file:



1. Download the latest Helm chart version to your local machine.

helm fetch --untar iks-charts/ibmcloud-backup-restore
2. Open the values.yaml file in the nano command line editor.

nano ibmcloud-backup-restore/values.yaml
3. Configure your Helm chart to back up or restore PVC data. You can configure the backup for more than one PVC.

Example to create a backup pod by configuring the values.yaml file:

image:
repository: icr.io/iks-charts/ibmcloud-backup-restore
pullPolicy: Always
tag: latest
Replace <src_repo> with the name of your namespace and repository in the format mynamespace/myrepo.

ibmcloud cr digests --restrict <src_repo>

For example, if you run the following command:

ibmcloud cr digests --restrict mynamespace/myrepo

You get the following response:

Listing images...

Repository Digest Tags Type Created Size Security status
icr.io/mynamespace/myrepo sha256:865b0c35e6da393b8e80b7e3799f777572399a4cff047eb02a81fa6e7a48ed4b - Docker Image Manifest V2, Schema 2 4 days ago 1.8 MB -
icr.io/mynamespace/myrepo sha256:a08e18417cec86f570be496b8bde1350dd986fc354d091b44d6a536570c26193 list Docker Manifest List - 433 B -

OK

In the previous example, you can see that only one image is in the same repository as the manifest list sha256:865b0c35e6da393b8e80b7e3799f777572399a4cff047eb02a81fa6e7a48ed4b and therefore, the manifest list is referencing another image sha256:1d71e323557502cc78ee6c237331a09b0c33ba59c14e5f683da3b1c6218779cc that does not currently exist in the repository.

You can resolve this issue by using one of the following options, following on from the previous example.



* If the missing image exists elsewhere in the registry, you can use the [ibmcloud cr image-tag](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_tag) command to move the image to the same repository.



1.