vania-janet/multiturn-rag-retrieval-data huggingface dataset:
"notification_email": "someone@example.com"
}
Show more
--enable-origin: Enable the origin within the Pool. The value can be ORIGIN_NAME or ORIGIN_ADDRESS.--disable-origin: Disable the origin within the Pool. The value can be ORIGIN_NAME or ORIGIN_ADDRESS.--add-origin: Add an origin into the Pool. ORIGIN_NAME and ORIGIN_ADDRESS are required. For example: --add-origin name=us-app-dal01,address=1.1.1.1,enabled=true,weight=0.5,host=example.com--remove-origin: Remove an origin from the Pool. The value can be ORIGIN_NAME or ORIGIN_ADDRESS.-s, --json-str: Deprecated. The JSON data used to describe a GLB pool.-j, --json-file: Deprecated. A file contains input JSON data.-i, --instance: Instance name or ID. If not set, the context instance specified by ibmcloud cis instance-set INSTANCE is used.--output: Specify output format, only JSON is supported.<-- </section "id="section-update-glb-pool-options" "> --><-- <section "id="section-update-glb-pool-examples" "> --> Examples Update GLB pool 17b5962d775c646f3f9725cbc7a53df4.
Get the details of your PV and note the ID of your AWS EBS instance that was created in the source.volumeHandle field.

oc describe pv <pv_name>
3. From the [AWS EC2 dashboard](https://console.aws.amazon.com/ec2/v2/home), select Elastic Block Store > Volumes.
4. Find your AWS EBS volume by using the ID that you retrieved earlier.









 Removing AWS EBS storage from your apps 

If you no longer need your AWS EBS instance, you can remove your PVC, PV, and the AWS EBS instance in your AWS account.

Removing your AWS EBS instance permanently removes all the data that is stored on this instance. This action cannot be undone. Make sure that you back up your data before you delete the AWS EBS instance.



1. List your PVCs and note the name of the PVC that you want to remove.

oc get pvc
2. Remove any pods that mount the PVC.



1. List all the pods that currently mount the PVC that you want to delete. If no pods are returned, you do not have any pods that currently use your PVC.

oc get pods --all-namespaces -o=jsonpath='{range .items[]}{"n"}{.metadata.name}{":t"}{range .spec.volumes[]}{.persistentVolumeClaim.claimName}{" "}{end}{end}' | grep "<pvc_name>"

Example output

app sat-aws-block-bronze
2. Remove the pod that uses the PVC. If the pod is part of a deployment, remove the deployment.

oc delete pod <pod_name>

oc delete deployment <deployment_name>
3. Verify that the pod or the deployment is removed.

oc get pods

oc get deployments



3. Delete the PVC.
Disconnecting a logging agent 

Detach a logging agent from a logging instance to stop collecting logs.



 Detaching a logging agent from a standard Kubernetes cluster 

To stop your Kubernetes cluster from sending logs to your IBM Log Analysis instance, you must remove the logging agent from your cluster.



 Detaching a logging agent by using the agent yaml file 

To stop your Kubernetes cluster from forwarding logs to your logging instance, complete the following steps from the command line:



1. Open a terminal. Then, [log in to the IBM Cloud](https://cloud.ibm.com/login), and follow the prompts.

Select the account where you provisioned the IBM Log Analysis instance.
2. 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>
3. Remove the secret from your Kubernetes cluster. The Kubernetes secret contains the logging ingestion key. Run the following command:

kubectl delete secret logdna-agent-key -n ibm-observe
4. Remove the logging agent on every worker(node) of your Kubernetes cluster. Run the following command:



 Type of endpoint Command 

 Public endpoint kubectl delete -f https://assets.<REGION>.logging.cloud.ibm.com/clients/logdna-agent/<VERSION>/agent-resources.yaml 
 Private endpoint kubectl delete -f https://assets.<REGION>.logging.cloud.ibm.com/clients/logdna-agent/<VERSION>/agent-resources-private.yaml 



Where



* <REGION> indicates the region where the logging instance is available. For more information about regions, see [Locations](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-regions).
* <VERSION> indicates the version of the agent that you have deployed.
service_name.alias.delete An event is generated when an alias for an instance is deleted. 







 Events for managing service credentials that are associated to a service instance 

A service credential provides the necessary information to connect an application to a service instance.

The following table lists the actions that generate an event:



Table 3. Actions that generate events

 Action Description 

 service_name.key.create An event is generated when an API key is created for a service instance through the Service credentials section of the service instance UI. 
 service_name.key.delete An event is generated when an API key that is associated with a service instance is deleted from the Service credentials section of the service instance UI. 







 Events for binding and unbinding a service instance to an app 

The following table lists the actions that generate an event:



Table 4. Actions that generate events

 Action Description 

 service_name.binding.create An event is generated when you bind a service instance to an application. 
 service_name.binding.delete An event is generated when you unbind a service instance from an application. 







 Where to look for the events 

Events are available in the Frankfurt (eu-de) region.

To view these events, you must [provision an instance](https://cloud.ibm.com/docs/services/activity-tracker?topic=activity-tracker-provisionprovision) of the IBM Cloud Activity Tracker service in the Frankfurt (eu-de) region. Then, you must [open the IBM Cloud Activity Tracker UI](https://cloud.ibm.com/docs/atracker?topic=atracker-launchlaunch_cloud_ui).





 Analyzing events 



 Action service_name.instance.delete 

When a service instance is deleted, consider the following information:



* Other actions are automatically triggered to clean up IAM permissions. These actions remove policies that are configured for users and service IDs in the account to work with the service instance.
* The initiator of these actions is an IBM service ID.
It is recommended that you set up an allowlist that ensures only [CIS IPs](https://cloud.ibm.com/docs/cis?topic=cis-cis-allowlisted-ip-addresses) can push objects into the Object Storage bucket. For more information on configuring an IP allowlist in Object Storage, see [Setting a firewall](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-setting-a-firewall).

Follow these steps to add an application.

You can configure one logpush job for each Object Storage object (also known as a destination). This means that you can have two log pushes at a time going to the same bucket, but to different objects. For example, one with HTTP and another with Range, both referring to different objects in same bucket.



1. Select the service.



* Choose Cloud Object Storage
* Select the dataset type
* Enter an description
* Copy the user ID to add to your COS bucket. Add a policy in your Cloud Object Storage Instance bucket with cislogp@us.ibm.com as a user with Object Writer role.
* Click "Next"



2. Configure your destination.



* Select a Cloud Object Storage instance from the list menu
* Select a bucket from the Bucket name list menu
* Enter a bucket region, if applicable
* Optionally, enter a bucket path
* Select the checkbox if you want to organize logs into daily subfolders
* Click "Next"



3. Verify ownership.



* Download the object you received in your bucket, and paste the token in the Ownership token text area
* You can resend the file from the Troubleshooting section, or return to the previous step if the bucket path is incorrect
* Click "Next"



4. Select the log fields that you want included in the log push.



* Verify that the logpush details are correct
* Select the logpush settings from the Timestamp and Frequency list menus
* Choose whether to enable the logpush job using the Enabled switch
Private endpoint kubectl delete -f https://assets.<REGION>.logging.cloud.ibm.com/clients/logdna-agent/<VERSION>/agent-resources-private.yaml 



Where



* <REGION> indicates the region where the logging instance is available. For more information about regions, see [Locations](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-regions).
* <VERSION> indicates the version of the agent that you have deployed. You must use a version that has a tag with the following format: X.Y.Z or use your custom yaml file.



5. To verify that the logging agent is deleted successfully, run the following command:

kubectl get pods -n ibm-observe

You should not see any logging pods.







 Detaching a logging agent by using kubectl commands 

To stop your Kubernetes cluster from forwarding logs to your logging instance, complete the following steps from the command line:



1. Open a terminal. Then, [log in to the IBM Cloud](https://cloud.ibm.com/login), and follow the prompts.

Select the account where you provisioned the IBM Log Analysis instance.
2. 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>
3. Remove the secret from your Kubernetes cluster. The Kubernetes secret contains the logging ingestion key. Run the following command:

kubectl delete secret logdna-agent-key -n ibm-observe
4. Remove the logging agent on every worker(node) of your Kubernetes cluster. The logging agent is responsible for collecting and forwarding your logs. Run the following command:

kubectl delete daemonset logdna-agent -n ibm-observe
5. To verify that the logging agent is deleted successfully, run the following command:
Debugging IBM Cloud Object Storage failures 

Review the options to debug Object Storage and find the root causes of any failures.



 Checking whether the pod that mounts your storage instance is successfully deployed 

Follow the steps to review any error messages related to pod deployment.



1. List the pods in your cluster. A pod is successfully deployed if the pod shows a status of Running.

oc get pods
2. Get the details of your pod and review any error messages that are displayed in the Events section of your CLI output.

oc describe pod <pod_name>
3. Retrieve the logs for your pod and review any error messages.

oc logs <pod_name>
4. [Review the Object Storage troubleshooting documentation for steps to resolve common errors](https://cloud.ibm.com/docs/openshift?topic=openshift-sitemapsitemap_object_storage).







 Restarting your app pod 

Some issues can be resolved by restarting and redeploying your pods. Follow the steps to redeploy a specific pod.



1. If your pod is part of a deployment, delete the pod and let the deployment rebuild it. If your pod is not part of a deployment, delete the pod and reapply your pod configuration file.



1. Delete the pod.

oc delete pod <pod_name>

Example output

pod "nginx" deleted
2. Reapply the configuration file to redeploy the pod.

oc apply -f <app.yaml>

Example output

pod/nginx created



2. If restarting your pod does not resolve the issue, [reload your worker nodes](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_worker_reload).
3. Verify that you use the latest IBM Cloud and IBM Cloud Kubernetes Service plug-in version.

ibmcloud update

ibmcloud plugin repo-plugins

ibmcloud plugin update
Then, you must [open the IBM Cloud Activity Tracker UI](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-launchlaunch_cloud_ui).





 Analyzing events 



 Action service_name.instance.delete 

When a service instance is deleted, consider the following information:



* Other actions are automatically triggered to clean up IAM permissions. These actions remove policies that are configured for users and service IDs in the account to work with the service instance.
* The initiator of these actions is an IBM service ID.



When the service instance that is deleted does not have IAM policies configured for users and service IDs, the events that are automatically generated for any of these resources report an outcome offailure with a 404 outcome code. The following sample shows the events that are generated when a service instance that does not have policies configured in the account is deleted:

Apr 30 09:04:16 Key Protect: delete instance Myinstance-v1
Apr 30 09:41:20 IAM Access Management: delete policy -failure
Apr 30 09:41:20 IAM Access Management: delete policy -failure
* [Optional] Enable or disable Sysdig captures. Check this box to allow this team to take IBM Cloud Monitoring captures.

Capture files will only be visible to members of this team.

Captures include detailed information from every container on a host, regardless of the team’s scope.
* [Optional] Enable or disable Infrastructure Events. Check this box to allow members to view all custom infrastructure events from every user and monitoring agent. When is not checked, users can see infrastructure events that are sent specifically to this team.
* [Optional] Enable or disable Platform Metrics. Check this box to allow members to view platform metrics. You can scope the metrics to limit the metrics team members can see.



7. Click Save.

Zoom

![Team Configuration](https://cloud.ibm.com/docs-content/v1/content/220cdcbf6f4421bd7fee83fd1028048dba3f16c8/monitoring/teams/images/team-configuration.png)

Team configuration







 Changing the scope of a team 

You must have manager role to change the scope of a team in a monitoring instance.

To change the scope of the data that is visible to members of a team, complete the following steps:



1. [Launch the web UI](https://cloud.ibm.com/docs/monitoring?topic=monitoring-launchlaunch).
2. Click the user icon. This is the icon with the initials of the logged on user. Then click Settings.
3. Select Teams. The list of existing teams is displayed.
4. Identify the team and select it. The details of the team are displayed.
5. Change configuration details in the Visibility section.
6. Click Save.







 Deleting a team 

You must have manager role to delete a team in a monitoring instance.

Complete the following steps to delete a team:

The default team, Monitor Operations, cannot be deleted.



1. Launch the web UI.
oc delete pod <pod_name>
5. Verify that the pod is removed.

oc get pods
6. Remove the PVC.

oc delete pvc <pvc_name>
7. Review the status of your PV. Use the name of the PV that you retrieved earlier as VOLUME. When you remove the PVC, the PV that is bound to the PVC is released. Depending on how you provisioned your storage, your PV goes into a Deleting state if the PV is deleted automatically, or into a Released state, if you must manually delete the PV. Note: For PVs that are automatically deleted, the status might briefly say Released before it is deleted. Rerun the command after a few minutes to see whether the PV is removed.

oc get pv <pv_name>
8. If your PV is not deleted, manually remove the PV.

oc delete pv <pv_name>
9. Verify that the PV is removed.

oc get pv
10. List the physical storage instance that your PV pointed to and note the id of the physical storage instance.

ibmcloud is volumes | grep <pv_name>
11. Remove the physical storage instance.

ibmcloud is volume-delete <vpc_block_id>
12. Verify that the physical storage instance is removed.

The deletion process might take up to 72 hours to complete.

ibmcloud is volumes
To ensure your app is responsive and highly available for basic operations and performance, complete the following steps:



1. Make sure your app is stateless and handles multiple connections. For more information about the best practices for constructing an app, see [The Twelve-Factor App](https://12factor.net/).
2. Deploy two or more instances of your app. Optimally, you want to deploy at least three instances, which is a standard IBM Cloud® deployment. Your instances are deployed to multiple hardware-isolated Availability Zones in a single IBM Cloud® multi-zone region; for example, US-SOUTH or EU-DE.







 High availability by using multiple regions 

To ensure your app is the most responsive and has the highest availability, complete the following steps:



1. Make sure your app is stateless and handles multiple connections. For more information about the best practices for constructing an app, see [The Twelve-Factor App](https://12factor.net/).
2. Deploy two or more instances of your app in multiple regions. Optimally, you want to deploy at least three instances in each region, which is a standard IBM Cloud® deployment for a region. Your instances are deployed to multiple hardware-isolated Availability Zones in each IBM Cloud® multi-zone region; for example, US-SOUTH and EU-DE.
3. Use a global load balancer.

IBM Cloud Foundry provides a load balancer to balance traffic within a single region. To balance traffic across multiple regions you must use a global load balancer such as [IBM Cloud® Internet Services](https://cloud.ibm.com/docs/cis?topic=cis-getting-started).

Each app that is deployed in a region is a separate URL target. A global load balancer connects multiple URLs and spreads the load over multiple regions.







 Scaling instances depending on load 

After you have a high-availability deployment, you can optimize your environment. For example, you might not need full capacity in every region. By scaling down regions that do not handle your primary workload you can save money on those regions and then autoscale the regions when those regions need to handle more traffic.
If your PV is not deleted, manually remove the PV.

oc delete pv <pv_name>
9. Verify that the PV is removed.

oc get pv
10. List the physical storage instance that your PV pointed to and note the id of the physical storage instance.

ibmcloud sl file volume-list --columns id --columns notes | grep <pv_name>

Example output for File Storage for Classic.

id notes
12345678 {"plugin":"ibm-file-plugin-5b55b7b77b-55bb7","region":"us-south","cluster":"aa1a11a1a11b2b2bb22b22222c3c3333","type":"Endurance","ns":"default","pvc":"mypvc","pv":"pvc-d979977d-d79d-77d9-9d7d-d7d97ddd99d7","storageclass":"ibmc-file-gold"}

"plugin":"ibm-file-plugin-5b55b7b77b-55bb7"
: The storage plug-in that the cluster uses.

"region":"us-south"
: The region that your cluster is in.

"cluster":"aa1a11a1a11b2b2bb22b22222c3c3333"
: The cluster ID that is associated with the storage instance.

"type":"Endurance"
: The type of file or block storage, either Endurance or Performance.

"ns":"default"
: The namespace that the storage instance is deployed to.

"pvc":"mypvc"
: The name of the PVC that is associated with the storage instance.

"pv":"pvc-d979977d-d79d-77d9-9d7d-d7d97ddd99d7"
4. Click Order a public certificate.
5. Name secure-file-storage.example.com.
6. Certificate authority: LetsEncrypt created earlier.
7. Key algorithm: RSA2048.
8. DNS provider: cis created earlier.
9. Select domains .
10. Open the cis example.com.
11. Click secure-file-storage.example.com created as a DNS CNAME record created earlier.
12. Click Done then Order.
13. Click the three vertical dots menu for the active secret and choose Show snippet and note the secret's PUBLIC_CERT_ID can be extracted from the command line. Export the value in the shell. It will look something like this:



export PUBLIC_CERT_ID=01234567-abcd-abcd-abcd-01234567abcd
5. Click Endpoints on the left. Make note of the Public URL in the Service API section. This is the Secrets Manager SECRETS_MANAGER_API_URL. Export it in the shell. Something like this:

export SECRETS_MANAGER_API_URL=https://01234567-0123-0123-0123-01234567abcd.us-south.secrets-manager.appdomain.cloud



This tutorial leverages the [External Secrets Operator](https://external-secrets.io/) to access the Secrets Manager service instance and the secret created from your cluster. A service ID and API key are required to provide access:



1. Create a service ID and set it as an environment variable.

export SERVICE_ID=ibmcloud iam service-id-create secure-file-storage-tutorial --description "A service ID for e2e security tutorial." --output json | jq -r ".id"; echo $SERVICE_ID
2. Assign the service ID permissions to read secrets from Secrets Manager.
- target: A valid hostname.
* The optional field is ttl.







Sample JSON data:

{
"type": "SRV",
"data": {
"service": "_ftp",
"proto": "_tcp",
"name": "testSRV",
"priority": 1,
"weight": 1,
"port": 21,
"target": "example.com"
}
}



* For type CAA:



* The required fields in JSON data are name, type, data:
* The optional field is ttl.





Sample JSON data:

{
"name": "testCAA.yourdomain.com",
"type": "CAA",
"data": {
"tag": "issue",
"value": "letsencrypt.org"
}
}

-s, --json-str
: Deprecated. The JSON data used to describe a DNS Record.

-j, --json-file
: Deprecated. A file contains input JSON data.

-i, --instance
: Instance name or ID. If not set, the context instance specified by ibmcloud cis instance-set is used.

--output
: Specify output format, only JSON is supported.





 Examples 

Create a dns record in domain 31984fea73a15b45779fa0df4ef62f9b.

ibmcloud cis dns-record-create 31984fea73a15b45779fa0df4ef62f9b --json '{"name": "testCNAME", "type": "CNAME", "content": "example.com"}' -i "cis-demo"
Valid values: 60, 120, 300, 600, 900, 1800, 3600, 7200, 18000, 43200.





Sample JSON data:

{
    "name": "testSRV"
    "rdata": {
        "priority": 100,
        "weight": 100,
        "port": 8000,
        "target": "siphost.com"
    },
    "service": "_sip",
    "protocol": "udp"
}







 ibmcloud dns resource-record 

Get a resource record details for a DNS zone.

ibmcloud dns resource-record ZONE_ID RECORD_ID [-i, --instance INSTANCE] [--output FORMAT]



 Command options 

ZONE_ID
: The ID of the DNS zone.

RECORD_ID
: The ID of resource record.

-i, --instance INSTANCE
: Instance name or ID. If the name is not set, the context instance specified by ibmcloud dns instance-target is used.

--output FORMAT
: Specify output format. Currently, json is the only supported format.







 ibmcloud dns resource-record-delete 

Delete a resource record for a DNS zone.

ibmcloud dns resource-record-delete ZONE_ID RECORD_ID [-i, --instance INSTANCE] [-f,--force]



 Command options 

ZONE_ID : The ID of the DNS zone.

RECORD_ID
: The ID of resource record.

-i, --instance INSTANCE
: Instance name or ID. If the name is not set, the context instance specified by ibmcloud dns instance-target is used.

-f, --force
: Delete resource record without prompting for confirmation.







 ibmcloud dns resource-records 

List all resource records for a DNS zone.

ibmcloud dns resource-records ZONE_ID [-i, --instance INSTANCE] [--output FORMAT]



 Command options 

ZONE_ID
: The ID of the DNS zone.

--page
* proto: A valid protocol.
* priority: Priority.
* weight: The record weight.
* port: The port of the service.
* target: A valid hostname.





* The optional field is ttl.



Sample JSON data:



{
"type": "SRV",
"data": {
"service": "_ftp",
"proto": "_tcp",
"name": "testSRV",
"priority": 1,
"weight": 1,
"port": 21,
"target": "example.com"
}
}



* For type CAA:



* The required fields in JSON data are name, type, data:
* The optional field is ttl.



Sample JSON data:



{
"name": "testCAA.yourdomain.com",
"type": "CAA",
"data": {
"tag": "issue",
"value": "letsencrypt.org"
}
}

-s, --json-str
: Deprecated. The JSON data used to describe a DNS Record.

-j, --json-file
: Deprecated. A file contains input JSON data.

-i, --instance
: Instance name or ID. If not set, the context instance specified by ibmcloud cis instance-set is used.

--output
: Specify output format, only JSON is supported.





 Examples 

Update a dns record in domain 31984fea73a15b45779fa0df4ef62f9b.