vania-janet/multiturn-rag-retrieval-data huggingface dataset:
To set a Git repository trigger, see [Deploying a new version of your app from a different branch](https://cloud.ibm.com/docs/satellite?topic=satellite-sat_toolchain_tutorialmodify_trigger).



To start a manual pipeline run, follow these steps.



1. On the Overview of your toolchain under Delivery pipelines, select the delivery pipeline to view its status.
2. Click Run pipeline.
3. Review the trigger properties to make sure that they match your configuration.
4. Click Run to run the toolchain and deploy your app.
5. Optional: Click the name of the run to see the status, logs, and details.
6. Optional: After the app is running, go to [Satellite Configuration](https://cloud.ibm.com/satellite/configuration) or run ibmcloud sat config command to see your Satellite Config resources.







 Step 9: Verifying that the sample app is running 

After your toolchain is set up and the Delivery Pipeline successfully completes, run the following steps to check your app.



1. From the [Clusters](https://cloud.ibm.com/satellite/clusters) page, click the cluster that you used to deploy your app.
2. Click OpenShift web console.
3. In the Workloads > Pod section, filter by the project or the cluster namespace, and verify that the pods are running.
4. In the Networking > Routes section, filter by the project or the cluster namespace, and locate the app URL.
5. Verify that the app is running by visiting the app URL with your browser.
6. Optional: You can view your Satellite configuration [in the console](https://cloud.ibm.com/satellite/configuration), or by running the ibmcloud sat config ls[command](https://cloud.ibm.com/docs/satellite?topic=satellite-satellite-cli-referencecli-config-configuration-ls).







 Step 10: Deploying a new version of your app from a different branch
: Enter the number of your replica starting with 0.

For example, if you must create 3 stateful set replicas, create 3 PVCs with the following names: nginxvol-nginx_statefulset-0, nginxvol-nginx_statefulset-1, and nginxvol-nginx_statefulset-2.

Looking to create a PVC and PV for an existing File Storage for Classic instance? Create your PVC and PV by using [static provisioning](https://cloud.ibm.com/docs/containers?topic=containers-file_storageexisting_file).
2. Follow the steps in [Dynamic provisioning: Creating the PVC when you create a stateful set](https://cloud.ibm.com/docs/containers?topic=containers-file_storagefile_dynamic_statefulset) to create your stateful set. The name of your PVC follows the format <volume_name>-<statefulset_name>-<replica_number>. Make sure to use the following values from your PVC name in the stateful set specification.

spec.volumeClaimTemplates.metadata.name
: Enter the <volume_name> of your PVC name.

metadata.name
: Enter the <statefulset_name> of your PVC name.

spec.replicas
: Enter the number of replicas that you want to create for your stateful set. The number of replicas must equal the number of PVCs that you created earlier.

If your PVCs are in different zones, don't include a region or zone label in your stateful set.
3. Verify that the PVCs are used in your stateful set replica pods by listing the pods in your cluster and identifying the pods that belong to your stateful set.

kubectl get pods
4. Verify that your existing PVC is mounted to your stateful set replica. Review the ClaimName in the Volumes section of your CLI output.

kubectl describe pod <pod_name>

Example output

Name: nginx-0
Namespace: default
After you create the new parameters, click OK to close the Configuration Parameters window. Click OK to close the Edit Settings window.



4. Create a DHCP binding for the worker VM:



1. Log in to NSX-T™.
2. Go to Networking > Segments.
3. Edit the ocp-internal segment.
4. Expand DHCP Static Bindings and click Set to open the Set Static Bindings window.
5. Review the list of existing bindings and make a note of the next available IP address.
6. Examine one of the existing worker bindings to look at information that you need later. Make a note of the gateway address and the DHCP options. To view the DHCP options, click Set next to DHCP Options. On the Options window, select Generic Options from the Select DHCP Option dropdown list. Make a note of the options that are set.
7. Close the existing binding that you were examining to return to the Set Static Bindings window.
8. Click Add IPV4 Static Binding. Complete the details for the new worker, including the DHCP options that you previously noted.
9. When you are done, click Save to commit the changes.



5. Add a worker to the Load Balancer pools:



1. Go to Networking > Load Balancer > Server Pools.
2. Edit the server pool named ocp-apps.
3. In the edit window, under Members/Group, click the blue numerical link. The default is 3.
4. When the Configure Server Pool Members window opens, click Add Member.
5. Enter the new worker's name and IP address. Leave the port number empty.
6. Click Save and then click Apply to commit your changes.



6. Create DNS records for the new worker.



1. Log in to the AD NS server for your vCenter Server instance.
2. Using the DNS Manager, add a new A record to the corresponding ocp zone.
volume_name
: Use the name that you want to specify in the spec.volumeClaimTemplates.metadata.name section of your stateful set, such as nginxvol.

statefulset_name
: Use the name that you want to specify in the metadata.name section of your stateful set, such as nginx_statefulset.

replica_number
: Enter the number of your replica, starting with 0.

For example, if you must create three stateful set replicas, create three PVCs with the following names: nginxvol-nginx_statefulset-0, nginxvol-nginx_statefulset-1, and nginxvol-nginx_statefulset-2.

Looking to create a PVC and PV for an existing storage device? Create your PVC and PV by using [static provisioning](https://cloud.ibm.com/docs/openshift?topic=openshift-block_storageexisting_block).
2. Follow the steps in [Dynamic provisioning: Creating the PVC when you create a stateful set](https://cloud.ibm.com/docs/openshift?topic=openshift-block_storageblock_dynamic_statefulset) to create your stateful set. The name of your PVC follows the format <volume_name>-<statefulset_name>-<replica_number>. Make sure to use the following values from your PVC name in the stateful set specification: spec.volumeClaimTemplates.metadata.name : Enter the <volume_name> of your PVC name.

metadata.name
: Enter the <statefulset_name> of your PVC name.

spec.replicas
: Enter the number of replicas that you want to create for your stateful set. The number of replicas must equal the number of PVCs that you created earlier.

If your PVCs are in different zones, don't include a region or zone label in your stateful set.
3. Verify that the PVCs are used in your stateful set replica pods by listing the pods in your cluster.
To set this value, use the same API calls as before, but with the new CRNs.



 Configuring Your IBM Cloud® Databases for MySQL time zone settings 

At provisioning, a Cloud Databases deployment is configured to Coordinated Universal Time. Reconfiguring your time zone is a persistent change, which must be undertaken for each of your Cloud Databases deployments.

Configuring your time zone sets the global time zone within your MySQL instance. In the instance that a failover occurs, your time zone setting is propagated as part of replication, as the time zone setting is written to the MySQL config file. The exception to this is if you restore an instance to a point in time before you configured your preferred time zone.

If you configure your time zone to one that features Daylight Saving Time, adjustments are part of the configuration. No action is necessary on your part. Using a specific time zone is better than using an offset time.

Cloud Databases validates the time_zone parameter value. If you configure your deployment with an invalid value, the configuration fails. The valid named time_zone values can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).





 Changing the time zone in the API 

Example offset:

curl -v -XPATCH -H "Authorization: Bearer $token" -H "Content-Type: application/json" https://api.<region>.databases.cloud.ibm.com/v5/ibm/deployments/<crn>/configuration -d '{"configuration": {"time_zone": "<EXAMPLE OFFSET"}}'

Example named time zone:

curl -v -XPATCH -H "Authorization: Bearer $token" -H "Content-Type: application/json" https://api.<region>.databases.cloud.ibm.com/v5/ibm/deployments/<crn>/configuration -d '{"configuration": {"time_zone": "<EXAMPLE TIME ZONE"}}'





 Changing the time zone in the CLI 

Example named time zone
Step 1. Set up the LogDNA Provider plug-in 

Complete the following steps to set up the LogDNA Provider plug-in for Terraform so that you can start managing resources:



1. Create a versions.tf file and specify the LogDNA Provider plug-in version that you want to use with the version parameter.

terraform {
required_providers {
logdna = {
source = "logdna/logdna"
version = "1.7.0"
}
}
}

To see the latest LogDNA provider version, see [LogDNA provider versions](https://registry.terraform.io/providers/logdna/logdna/latest).
2. Store the versions.tf file in your Git repository or the folder where Terraform is set up.







 Step 2. Configure the LogDNA Provider plug-in 

Before you can start working with Terraform, you must retrieve the credentials and parameters that are required for a Terraform resource or data source, and specify them in the provider configuration. This configuration is used by the LogDNA Provider plug-in to authenticate with the service that runs in the IBM Cloud platform and to view, create, update, or delete resources.

The following table lists input parameters that you can set in the provider block of your Terraform on your Terraform configuration file:



Table 1. List of input parameters that you can set in the provider block of your Terraform

 Input parameter Required / optional Description 

 servicekey Required API key that you must use to validate your credentials with the logging instance. 
 url Required API endpoint. For more information, see [API Endpoints](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-endpointsendpoints_api). 



For more information on how to use environment variables, see [Using environment variables](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-provider-referenceenv-vars).
Setting an IAM access policy with the console 



1. Navigate to the Service IDs tab in the IAM console.
2. Click the service ID that corresponds to your Cloud Functions namespace.
3. On the Manage page, click Access policies.
4. Click Assign access.
5. Click Assign access to resources.
6. From Services, select Cloud Object Storage.
7. From Service instance, select your IBM Cloud Object Storage instance.
8. To limit access to a specific bucket, enter bucket for Resource type and enter your bucket-name for Resource ID.
9. Review the [IAM roles](https://cloud.ibm.com/docs/cloud-object-storage/iam?topic=cloud-object-storage-iam-bucket-permissionsiam-service-id) and select the appropriate role to assign to your namespace.
10. After you have selected a role, click Save.







 Setting an IAM access policy with the CLI 

Copy the following command and replace the variables.

ibmcloud iam service-policy-create <service-id-name> --roles <role> --service-name cloud-object-storage</br> --service-instance <resource-instance-id> --region global</br> --resource-type bucket --resource <bucket-name>



* Replace service-id-name with the name of your Cloud Functions namespace.
* Replace role with the [IAM role](https://cloud.ibm.com/docs/account?topic=account-userroles) you want to assign to your Cloud Functions namespace.
* (Optional) Include the --resource-type bucket and --resource <bucket-name> flags to limit access to a specific bucket. If you do not include these flags, access is granted at the service level.
* Replace <bucket-name>. with the name of your bucket.



You still need to pass the bucket name and endpoint during action invocation.
Complete these steps if you previously set deployment values for an existing version and want to import the values to your current version.

Imported values don't replace any deployment values that you already added to your current version.



1. Click Configure version > Next.
2. Click Add deployment values.
3. Click Import values from a previous version.
4. Select the version that contains the values that you want to import.
5. Click Import.
6. To customize parameters, select a parameter and click Edit.









 Editing output value descriptions 

You can improve the descriptions for your Terraform template's output values to help users better understand the purpose of the parameters. The description of any output value that you include in your template can be updated.

To add output values, you need to include them in a new imported version of your Terraform template.

Complete the following steps to edit the product's output value descriptions:



1. Click Configure version > Next.
2. From the Output value descriptions section, provide a new description for the parameter that you want to update.
3. Click Next.







 Defining IAM access 

If applicable to your software type, you can add the service access and platform access roles that are required to install your product from the IBM Cloud catalog. You can define new IAM access or import IAM access that you set in an earlier version.



 Defining new IAM access 

Use the following steps to define your product's access:



1. Click Configure version > Next > Next.
2. Click Add.
3. Select the service and the required service and platform access.



* The service access role allows access for using the service and performing service API calls.
* The platform access role enables actions to be performed on platform resources, such as creating an instance, connecting instances to apps, and assigning user access.



4. Click Save.







 Importing existing IAM access 

Complete the following steps if you previously defined IAM access for an existing version and want to import the values to your current version.
* Be sure you set up the [IBM Cloud CLI](https://cloud.ibm.com/docs/satellite?topic=satellite-setup-cli), the plug-in for Satellite commands, and other related CLIs.
* If you did not create a Satellite location, see [Setting up Satellite locations](https://cloud.ibm.com/docs/satellite?topic=satellite-locations). Follow the steps in the [Manually creating Satellite locations](https://cloud.ibm.com/docs/satellite?topic=satellite-locationslocation-create) documentation.



* For the management location, choose Washington DC. If you are creating your Satellite location on AWS, adjust the host zones to AWS-default zone names, for example: us-east-1a, us-east-1b, us-east-1c.





As ICD enabled by IBM Cloud Satellite solely supports resource deployment in the us-east region, you must choose the Washington DC location when provisioning.



* Before Step 1, have your Satellite location set up properly and ensure that the Satellite control plane is up and running.
* escapeTokenInputs - Specify whether the token inputs are URL escaped before generating the token. By default, inputs are URL escaped. This setting must match the setting that is used in the token generation code. Possible values 0 and 1. If set to 1, input values are escaped before adding them to the token. Default value is 1.
* ignoreQueryString - Specify whether the query string is included in the URL input into the token. By default, the query string is included. This setting must match the setting that is used in the token generation code. Possible values 0 and 1. If set to 1, query strings are removed from a URL when computing the token’s HMAC algorithm. Default value is 0.
* transitionKey - The token transition key. It's an alternate key/shared secret to validate tokens, which you can use to avoid downtime when rotating keys. Either the primary or transition key setting must match the key that is used in the token generation code. This specifies an even number of hex digits for the token transition key. An entry can be up to 64 characters in length.
On the Toolchains page, click Create toolchain. On the Create a Toolchain page, click CC - Keep your app continuously Compliant with DevSecOps practices.







 Step 2: Set up the CC toolchain name and region 

The setup starts with a Welcome page that explains the toolchain, prerequisites needed to set this up, useful links like documentation or tutorial, and a framework diagram that explains the correlation between different integrated tools.

Zoom

![DevSecOps CC toolchain welcome page](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/devsecops-cc-toolchain-setup-Welcome.png)

Figure 1. DevSecOps CC toolchain welcome page

Review the default information for the toolchain settings. The toolchain's name identifies it in IBM Cloud. Make sure that the toolchain's name is unique within your toolchains for the same region and resource group in IBM Cloud.

The toolchain region can differ from cluster and registry region.

Zoom

![DevSecOps CC toolchain name and region](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/devsecops-cc-toolchain-setup-toolchain-name-region.png)

Figure 2. DevSecOps CC toolchain name and region

You can provide a CI toolchain already setup at this step. Using filter on the region where your CI toolchain resides helps you to find it easily.

The setup fetches the resource details such as pipeline configuration, repositories like inventory and incidence issues based on the CI toolchain provided.
Renaming or deleting assistants 

If necessary, you can rename or delete an assistant. You can't change the language of an assistant once it is set.



  Renaming an assistant 

You can change the name and description of an assistant after you create it.

To rename an assistant, follow these steps:



1.  Switch to the assistant you want to rename.
2.  Open Assistant settings.
3.  In Details, enter a new name or description.
4.  Click Save.







  Deleting an assistant 

To delete an assistant, follow these steps:



1.  Switch to the assistant you want to delete.
2.  Open Assistant settings.
3.  Click the Delete assistant button on the settings page. A confirmation question displays.
4.  To confirm, type the word DELETE, then click Delete.
You don't need to include the entire set of available parameters in the JSON, only the advanced deployment options that you selected in the console along with the parameters that you want to override. For example, if you want to deploy a peer and override the chaincode startup timeout and specify a different port for the statsd address, you would paste in the following JSON:

{
"peer": {
"chaincode": {
"startuptimeout": "600s"
}
},
"metrics": {
"statsd": {
"address": "127.0.0.1:9443"
}
}
}





 Modifying peer settings after deployment 

After a peer is deployed, a subset of the fields can be updated as well. Click the peer tile in the console and then the Settings icon to open a side panel. Click Edit configuration JSON (Advanced) to open the panel where you can override the peer settings. The JSON in the Current configuration box contains the current settings for the peer. Not all of these values can be overridden after the peer is deployed. A subset of these parameters can be overridden by pasting a JSON with the overrides into the Configuration JSON box. Again, you don't need to include the entire set of parameters from the Current configurationJSON, only paste the parameters you want to override into the Configuration JSON box.

The following subset of parameters can be overridden after a peer is deployed:

{
"peer": {
"id": "jdoe",
"networkId": "dev",
"keepalive": {
"minInterval": "60s",
"client": {
"interval": "60s",
"timeout": "20s"
},
"deliveryClient": {
"interval": "60s",
"timeout": "20s"
}
},
"gossip": {
"useLeaderElection": true,
"orgLeader": false,
First, get the command to set the environment variable and download the Kubernetes configuration files.

ibmcloud ks cluster config --cluster <cluster_name_or_ID>
2. Edit the sysdig-agent-configmap.yaml file.

Run the following command:

kubectl edit configmap sysdig-agent -n ibm-observe
3. Make changes. Add the events section or update the section.

events:
kubernetes: none
4. Save the changes.



Changes are applied automatically.





 Including and excluding metrics 

To filter custom metrics, you must customize the metrics_filter section in the sysdig-agent-configmap.yaml file. You can specify which metrics to include and which ones to filter out by configuring the include and exclude filtering parameters.

The filtering rule order is set as follows: the first rule that matches a metric is applied. Follow up rules for that metric are ignored.

Complete the following steps:



1. Set up the cluster environment. Run the following commands:

First, get the command to set the environment variable and download the Kubernetes configuration files.

ibmcloud ks cluster config --cluster <cluster_name_or_ID>
2. Edit the sysdig-agent-configmap.yaml file.

Run the following command:

kubectl edit configmap sysdig-agent -n ibm-observe
3. Make changes. Add the metrics_filter section or update the section.

For example, if the metrics_filter section of a monitoring agent looks as follows:

metrics_filter:
- include: metricA.
- exclude: metricA.
- include: metricB.
- include: haproxy.backend.
- exclude: haproxy.
- exclude: metricC.



* You are configuring the monitoring agent to collect all data from metrics that start with metricA, metricB, and haproxy.backend.
6. Leave the access control list set to VPC default.
7. Leave the public gateway set to Detached.
8. Select Save.



8. Click Create virtual private cloud.







 Step 2: Create subnets 

You create three extra subnets for your first availability zone (vcp-region1-zone1) and use the VPC you created in Step 1:



* subnet-web
* subnet-app
* subnet-db



To create the subnets:



1. Click Subnet
2. Click Create.
3. Enter subnet-web as a unique name for your subnet.
4. Select vpc-some-application as the VPC.
5. Select a Resource group.
6. Select a location and zone for example: Sydney and Sydney 1.
7. Select the wanted number of IP addresses.
8. Leave the Subnet access control list set to the default selection.
9. Leave the Public gateway to Detached.
10. Click Create subnet.
11. Repeat steps 1-10 for the other two subnets and:



* Create a subnet that is called subnet-app for application
* Create a subnet that is called subnet-db for db





To confirm that the subnets are created, click Subnets on the left panel and wait until the status changes to Available.





 Step 3: Create security groups to control communications between VSIs 

To specify which traffic to allow to the application, you deploy rules, which you add to the virtual server instances in the later steps. * Enable an inbound rule for SSH traffic to bastion server * Enable specific ports for the corresponding application of each tier. For example, if the front-end server needs HTTPs, then a security group is needed to allow for 443.

To create the security groups:



1. Go to Security groups.
2. Verify that the Regions setting is correct and if not then select the correct region, for example: Sydney
3. Click Create.
4. Create the security group bastion-sg:



1.