vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Managing the Monitoring agent in a Kubernetes cluster by using a HELM chart 

You can use a Helm chart to install, upgrade, and delete a Monitoring agent on a Kubernetes cluster.



 Before you begin 



* Install the latest release of the version 3 [Helm CLI](https://github.com/helm/helm/releases) on your local machine.

[Helm](https://helm.sh) is a Kubernetes package manager that uses Helm charts to define, install, and upgrade complex Kubernetes apps in your cluster. Helm charts package the specifications to generate YAML files for Kubernetes resources that build your app. These Kubernetes resources are automatically applied in your cluster and assigned a version by Helm. You can also use Helm to specify and package your own app and let Helm generate the YAML files for your Kubernetes resources.
* Check that you have access and permissions to deploy the Monitoring agent on the cluster.
* Verify the ibm-observe namespace is available in your cluster. The agent is deployed in this namespace.







 Deploy an agent 

Complete the following steps to deploy an agent by using Helm:



 Step 1. Setup de Sysdig Helm repository 

Add the Monitoring Helm repository to your Helm instance.

Complete the following steps:



1. Set the cluster context.

ibmcloud ks cluster config --cluster <CLUSTER_NAME>
2. Add the Helm repository.

helm repo add sysdig https://charts.sysdig.com
3. Update the repos to retrieve the latest versions of all Helm charts.

helm repo update
4. List the Helm charts that are currently available for the Sysdig repo.

helm search repo sysdig
5. Verify the Helm chart sysdig/sysdig-deploy is listed.



If you get the following error:

helm repo add sysdig https://charts.sysdig.com --debug
Error: context deadline exceeded
helm.go:84: [debug] context deadline exceeded

Run the following command and try again.
NSX Manager FQDN The NSX Manager fully qualified domain name (FQDN). 
 NSX Manager HTTP The username and password that is used to access the NSX Manager web console. 
 NSX Controllers IPs<br><br>[8] The IP address or addresses for the NSX node VM. 
 NSX Controllers SSH<br><br>[9] The username and password that you can use to access the NSX node VM through KVM or SSH connection. 
 Customer Edge VM IPs<br><br>[10] The IP address or addresses for the Customer Edge VM. 
 Customer Edge VM SSH<br><br>[11] The username and password that you can use to access the Customer Edge VM through KVM or SSH connection. 
 NSX Service Edge VM IPs<br><br>[12] The IP address or addresses for the Service Edge VM. 
 NSX Service Edge VM SSH<br><br>[13] The username and password that you can use to access the Service Edge VM through KVM or SSH connection. 







 Procedure to view deployment history for vCenter Server instances 

Click the Deployment history tab to view the deployment history for the instance.



Table 5. vCenter Server instance deployment history

 Item Description 

 Date The date and time when the instance status is changed. 
 Summary The details of the change. 





 What to do if errors occur 

If you see errors in the deployment history, the IBM Cloud Support team is automatically notified. To inquire about the status of your ticket, follow the steps in [Contacting IBM Support](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-trbl_support).







 What to do next 

Manage your instances from the IBM Cloud for VMware Solutions console or the VMware vSphere Web Client.

Before you click vCenter console on the instance summary page to go to the vSphere Web Client and start managing your VMware ESXi™ servers, you must log in to the VPN portal of the IBM Cloud data center.
Queue manager <br><br> * Provide a highly available queue manager deployment<br> * Configure channels and queues for testing purposes<br> * Monitoring of queue manager availability<br><br><br> <br><br> * Select the [queue manager size](https://cloud.ibm.com/docs/services/mqcloud?topic=mqoc_qm_sizes) based on messaging requirements<br> * Monitor [IBM Cloud status](https://cloud.ibm.com/status/maintenance?component=mqcloud) for planned maintenance<br> * Configuring and monitoring queue depth to ensure storage requirements do not exceed limits<br> * Monitoring open connections to ensure they do need exceed limits<br> * Configure multiple queue managers in different regions to provide additional [high availability](https://cloud.ibm.com/docs/services/mqcloud?topic=mqoc_ha)<br><br><br> 
 Certificates <br><br> * Provide Let's Encrypt signed certificates<br> * Refresh provided certificates before expiry<br><br><br> <br><br> * Optionally: [Import user defined certificate chains](https://cloud.ibm.com/docs/services/mqcloud?topic=mqoc_qm_certs)<br> * Ensure that user provided certificates do not expire<br> * Configure certificate usage on queue manager channels<br><br><br> 







 Change Management 

You and IBM share responsibilities for managing queue manager changes in the IBM MQ on IBM Cloud environment. You are responsible for change management of your application data.



Table 3. Responsibilities for change management
The rows are read from left to right. The resource area of comparing responsibilities is in the first column, with the responsibilities of IBM in the second column and your responsibilities in the third column.

 Resource IBM responsibilities Your responsibilities
To view events, you must access the web UI of the Activity Tracker service in the same location where your service instance is available. For more information, see [Launching the web UI through the IBM Cloud UI](https://cloud.ibm.com/docs/atracker?topic=atracker-launch).







 Management events 



 Targets 

The following table lists the auditing events that are generated when you manage targets:



Table 1. Events for managing targets

 Action Description 

 atracker.target.create This event is generated when an administrator creates a new Cloud Object Storage (COS) target with specified COS endpoint information and credentials. 
 atracker.target.list This event is generated when an administrator lists all Cloud Object Storage (COS) targets defined under a region. 
 atracker.target.get This event is generated when an administrator retrieves a target and its details by specifying the ID of the target. 
 atracker.target.update This event is generated when an administrator updates a target details by specifying the ID of the target. 
 atracker.target.delete This event is generated when an administrator deletes a target by specifying the ID of the target. 







 Routes 

The following table lists the auditing events that are generated when you manage routes:



Table 2. Events for managing routes

 Action Description 

 atracker.route.create This event is generated when an administrator creates a route with rules defined how to route auditing events to targets for a region. 
 atracker.route.list This event is generated when an administrator lists routes defined under this region. 
 atracker.route.get This event is generated when an administrator retrieves a route and its details by specifying the ID of the route. 
 atracker.route.update This event is generated when an administrator replaces a route details by specifying the ID of the route. You can also get this event when you validate a target by checking the credentials to write to the bucket. 
 atracker.route.delete This event is generated when an administrator deletes a route by specifying the ID of the route. 







 Endpoints 

The following table lists the auditing events that are generated when you manage endpoints:



Table 3.
Managing shared processor pool 

A shared processor Pool (SPP) is a pool of processor capacity that is shared between a group of virtual server instances. Unlike a virtual server instance that has a dedicated and defined maximum amount of processing capacity, you can set the reserved cores in SPP that are guaranteed to be available at the pool level.

The following table shows how an SPP is used to reduce the licensing cost when you pay per core:



Table 1. SPP helps to reduce the licensing cost

 Use of SPP VM 1 VM 2 Reserved cores in Pool (User defined) License requirement per core 

 No Maximum cores = 5 <br>Mode = Dedicated Maximum cores = 6 <br>Mode = Dedicated NA 5+6 = 11 
 Yes Maximum cores = 5 <br>Mode = Shared/Uncapped <br>Entitled capacity = 4.25 Maximum cores = 6 <br>Mode = Shared/Uncapped <br>Entitled capacity = 5.25 Maximum cores = 10 10, Determined by reserved cores in pool 



The benefits of using an SPP are as follows:



* Provides control over licensing costs by limiting the number of processors an uncapped partition can use, which reduces the number of software licenses.
* Provides a better overall ability to manage processor resources.



The Power Systems Virtual Server always has at least one defined SPP as the default pool. You can add up to 63 more SPPs to a single Power Systems Virtual Server workspace. The SPP is used and shared by a set of virtual server instances of the same machine type (host).

You can specify the host affinity and anti-affinity between two or more SPPs with shared processor pool placement groups. For more information, see [Configuring shared processor pool placement group](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-manage-SPPconfigure-SPP-PG).



 Pricing for shared processor pool 

When you use SPP, you pay for the following items:



* SPP reserved cores that use the shared capped part number.
* Virtual server instance cores that are deployed into the SPP that use shared uncapped part number.



The SPP helps you to manage CPU cores only. Pricing for memory and storage remains the same as earlier.
Iterative development and deployment can result in apps that expand quickly. Your delivery process design must be able to scale up quickly and easily. You want continuous development with a fast deployment rate. Having your development and production spaces in the same organization provides access to the same resources. Managing different spaces within a single organization reduces the administration workload. The development, test, and operations personnel can collaborate easily if they are working within the same organization.

Implement a naming standard to clearly identify the organization and space usage. For example, you might include the type of cloud, the geographical region, the usage type (such as development, test, production), the app name, and the version or revision number. The organizations and spaces can then be easily identified for administration and access purposes.

The number of spaces can multiply rapidly because of iterative development. You can define as many spaces as you need within an organization. If you plan to define many spaces, you might want to create an app to help manage the spaces. When the number of spaces exceeds sixty, you might want to consider defining another organization.

Have one person create and manage an organization, define the spaces, and grant team member access. A second person can be given the same access to maintain the environment when the organization manager is disabled.

Identify all of the people who need access to each space and organization. Determine their role. The job role of a team member determines their authority. For example, a senior developer needs the authority to view and update the entire development environment. However, a junior developer is limited as to what they can view and update.
Managing the Monitoring agent in Red Hat OpenShift by using a HELM chart 

You can use a Helm chart to install, upgrade, and delete a Monitoring agent on a Kubernetes cluster.



 Before you begin 



* Install the latest release of the version 3 [Helm CLI](https://github.com/helm/helm/releases) on your local machine.

[Helm](https://helm.sh) is a Kubernetes package manager that uses Helm charts to define, install, and upgrade complex Kubernetes apps in your cluster. Helm charts package the specifications to generate YAML files for Kubernetes resources that build your app. These Kubernetes resources are automatically applied in your cluster and assigned a version by Helm. You can also use Helm to specify and package your own app and let Helm generate the YAML files for your Kubernetes resources.
* Check that you have access and permissions to deploy the Monitoring agent on the cluster.
* Verify the ibm-observe namespace is available in your cluster. The agent is deployed in this namespace.







 Deploy an agent 

Complete the following steps to deploy an agent by using Helm:



 Step 1. Setup de Sysdig Helm repository 

Add the Monitoring Helm repository to your Helm instance.

Complete the following steps:



1. Set the cluster context.

obmcloud ks cluster config --cluster <CLUSTER_NAME>
2. Add the Helm repository.

helm repo add sysdig https://charts.sysdig.com
3. Update the repos to retrieve the latest versions of all Helm charts.

helm repo update
4. List the Helm charts that are currently available for the Sysdig repo.

helm search repo sysdig
5. Verify the Helm chart sysdig/sysdig-deploy is listed.



If you get the following error:

helm repo add sysdig https://charts.sysdig.com --debug
Error: context deadline exceeded
helm.go:84: [debug] context deadline exceeded

Run the following command and try again.
* [Add the Delivery Pipeline tool integration](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-deliverypipeline) to an existing toolchain.



From your Delivery Pipeline, change your configuration; check the status of builds, the deployed app, and recent deployments; see the most recent logs and deployment details; or delete your pipeline.





 Viewing a pipeline by using the CLI 

To get the details that are required to invoke a pipeline, run the ibmcloud dev toolchains command to view the name of the toolchain. If you already know the name of the toolchain, run the ibmcloud dev toolchain-get [toolchain-name] to view the toolchain details.



* To get the details of a pipeline and its stages, identify the pipeline and its ID to run the following command:

ibmcloud dev pipeline-get [pipelineID]
* Using the pipeline ID from the previous command, you can now run the pipeline:

ibmcloud dev pipeline-run [pipelineID]

This command invokes an execution of the stage and its jobs. A successful execution results in the job execution for each job in the selected stage.





 Viewing pipeline logs by using the CLI 

You can view detailed output of each stage during a pipeline's execution.



* To view the logs from a pipeline's execution, run the following command:

ibmcloud dev pipeline-log [pipelineID]
* To filter the logs by stage, apply the previous command and add the stage ID:

ibmcloud dev pipeline-log [pipelineID] --stage-id [stageID]
Click a policy name.
3. Click the Applied resources tab.



A list of Block Storage for VPC volumes that are backed up by this policy is shown. Information about the volumes includes the volume name, status, volume size, and encryption type (see Table 3).



Table 3. List of Block Storage for VPC volumes for the backup policy

 Field Description 

 Name Name of the volume. Click the pencil icon to edit. 
 Status [Status of the volume](https://cloud.ibm.com/docs/vpc?topic=vpc-managing-block-storagestatus). 
 Size Size of the volume in GBs. 
 Encryption [IBM-managed encryption](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-encryption-aboutvpc-provider-managed-encryption) or [customer-managed encryption](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-encryption-aboutvpc-customer-managed-encryption). 
 Add volume Add a volume to this policy. The informational side panel provides a list of tags for target resources that you can apply to the volume, and a link to the [list of Block Storage for VPC volumes](https://cloud.ibm.com/docs/vpc?topic=vpc-viewing-block-storage&interface=uiviewvols-ui). You must apply at least one of the policy's tags for target resources to the volume. 



You can also view a more detailed list of all Block Storage for VPC volumes in your account region, including user tags that are applied to the volume. For more information, see [View information about all Block Storage for VPC volumes in the UI](https://cloud.ibm.com/docs/vpc?topic=vpc-viewing-block-storage&interface=uiviewvols-ui).

When you click a volume name to see the details, you need administrator privileges to access the information.







 Viewing backup policies from the CLI 

You can view backup policies by using the CLI.



 Before you begin
Execute the Bell circuit
with Session(service=service, backend="ibmq_qasm_simulator"):
sampler = Sampler(options=options)
job = sampler.run(circuits=bell)
print(job.result())

 You can invoke run() multiple times.
job = sampler.run(circuits=bell)
print(job.result())
Show more

Alternatively, you can use the [Run a job API](https://cloud.ibm.com/apidocs/quantum-computingcreate-job); optionally use [Swagger](https://us-east.quantum-computing.cloud.ibm.com/openapi//Jobs/create_job). You must specify the program ID and can optionally supply parameters and the backend to run on. Note the job ID that is returned. You need this information to check the status and view results.

If you do not specify the backend, the job is sent to the least busy device that you have access to.

To ensure fairness, a maximum execution time for each Qiskit Runtime job exists. If a job exceeds this time limit, it is forcibly ended. The maximum execution time is the smaller of 1) the system limit and 2) the max_execution_time defined by the program. The system limit is three hours for simulator jobs and eight hours for jobs that are running on a physical system.





 Step 2: (Optional) Return the job status 

Follow up the Qiskit Runtime QiskitRuntimeService.run() method by running a RuntimeJob method. The run() method returns a RuntimeJob instance, which represents the asynchronous execution instance of the program.

Several RuntimeJob methods exist, including job.status():

job.status()
Managing control panel licenses 

You can manage the licenses for active control panel software, like cPanel and Parallels, from the IBM Cloud console on the Control Panel Licenses window. You can view licenses and their associated IPs, download license files, and cancel individual licenses.



 Before you begin 

First, go to the device menu and ensure you have the correct account permissions to complete the tasks.



* Go to your console's device menu. For more information, see [Navigating to devices](https://cloud.ibm.com/docs/bare-metal?topic=virtual-servers-navigating-devices).
* Make sure that you have any necessary account permissions and device access. Only the account owner, or a user with the Manage Users classic infrastructure permission, can adjust the permissions.



For more information about permissions, see [Classic infrastructure permissions](https://cloud.ibm.com/docs/iam?topic=iam-infrapermissioninfrapermission) and [Managing device access](https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-managing-device-access).





 Downloading a control panel license to a device 

A license file is used to verify that the license is valid for software on a device, and any software features that are enabled. You can download license files from the IBM Cloud console, but only on the device that runs the corresponding control panel software. Use the following steps to download a license file.



1. Select Devices > Manage > Control Panel Licenses from the menu to access the Control Panel Licenses window.
2. Select Actions > Download License File for the license.
3. Save or download the file to the control panel software on the device by using the prompts provided by the device's operating system.



After you download the license file to the device, the control panel software's details about the license are updated. If issues occur or if the download wasn't successful, try the download process again by repeating the previous steps.





 Canceling a control panel license 

Control panel licenses are invoiced monthly, based on the agreed-upon terms at the time the license was purchased.
Click Overview to view the blueprint summary, that includes Modules status, Variables summary, Blueprint Details and Recent Job runs of your blueprint.



* Optional: From the Modules status card, Click View details to navigate to the module details page.
* Optional: From Variables summary card, Click View details to navigate to the variable summary page.



3. Click Modules tab to see the list of blueprint modules and their current status.



* Optional: Click Show details to view more details about the blueprint module definition.
* Optional: Click Name that will take you to the modules related Schematics Workspace page.



4. Click Resources tab to view the list of resources provisioned by the blueprint.
5. Click Variables tab to view the blueprint Inputs and Outputs variables and values. Optional: on this page you can edit the input variable values and save.
6. Click Jobs history tab view the job logs of the blueprint and module jobs.
7. Click Settings tab to view and edit the configuration settings of the blueprint.







 Next steps 

You have now deployed a blueprint and created a multi-module environment. Optionally, you can clean up the deployed blueprint by using [destroy](https://cloud.ibm.com/docs/schematics?topic=schematics-destroy-blueprintdestroy-blueprint-ui) to remove the cloud resources and [delete](https://cloud.ibm.com/docs/schematics?topic=schematics-delete-blueprintdelete-blueprint-ui) to remove the blueprint config.

For more information about the difference between destroy and config delete, see [Deleting a blueprint](https://cloud.ibm.com/docs/schematics?topic=schematics-delete-blueprints).



* Learn [about Schematics Blueprints](https://cloud.ibm.com/docs/schematics?topic=schematics-blueprint-intro).
* Looking for template samples?
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.

oc 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.

oc describe pod <pod_name>

Example output

Name: nginx-0
Namespace: default
Node: 10.xxx.xx.xxx/10.xxx.xx.xxx
Start Time: Fri, 05 Oct 2022 13:24:59 -0400
...
Volumes:
myvol:
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName: myvol-nginx-0
...









 Changing the size and IOPS of your existing storage device 

If you want to increase storage capacity or performance, you can modify your existing volume.

For questions about billing and to find the steps for how to use the IBM Cloud console to modify your storage, see [Expanding File Share capacity](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-expandCapacityexpandCapacity).



1. List the PVCs in your cluster and note the name of the associated PV from the VOLUME column.

oc get pvc

Example output

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
myvol Bound pvc-01ac123a-123b-12c3-abcd-0a1234cb12d3 20Gi RWX ibmc-file-bronze 147d
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