vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For example, the following command lists all the pods in the namespace ibm-observe.

oc get pods -n ibm-observe



The deployment is successful when you see one or more logging pods.



* The number of logging pods equals the number of worker nodes in your cluster.
* All pods must be in a Running state.
* Stdout and stderr are automatically collected and forwarded from all containers. Log data includes application logs and worker logs.
* By default, the logging agent pod that runs on a worker collects logs from all namespaces on that node.



After the agent is configured, you should start seeing logs from this cluster in the logging UI. If after a period of time you cannot see logs, check the agent logs.

To check the logs that are generated by a logging agent, run the following command:

oc logs logdna-agent-<ID>

Where ID is the ID for a logging agent pod.

For example,

oc logs logdna-agent-xxxkz

Next, launch the logging UI to verify that logs from the cluster are available through the UI. See [Navigating to the web UI](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-launch) and [Viewing logs](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-view_logs).







 Deploy the logging agent within the context of the cluster 

When you deploy and connect a logging agent within the context of the cluster, consider the following information:



* You can launch the logging UI from the OpenShift cluster UI in IBM Cloud.
* The view that opens displays logs for your cluster.
* The agent is deployed in the ibm-observe namespace.
* A tag that informs about the cluster name is associated to each log line as metadata.
* A tag that informs about the version of the agent is associated to each log line as metadata.
* The logging instance must be available in the same IBM Cloud account where the cluster is provisioned.
* The logging instance can be in a different resource group and IBM Cloud region than your cluster.
CRN crn:v1:bluemix:public:is:eu-de:a/a10d63fa66daffc9b9b5286ce1533080::backup-policy:r138-8c494618-9e4f-4b67-9a08-ee3491404f3b
Status pending
Plans ID Name Resource type

Backup tags dev:test
Backup resource type volume
Resource group defaults
Created at 2023-02-21T18:37:17+00:00

For more information about available command options, see [ibmcloud is backup-policy-create](https://cloud.ibm.com/docs/cli?topic=cli-vpc-referencebackup-policy-create).





 Creating a backup policy with a plan from the CLI 

Run the backup-policy-create command to create a backup policy and a backup plan in the same command.

The following example uses the --match_tags option to match tags to volumes with the user tag dev:test and specifies the frequency of the backup plan as a cron-spec expression. The --plan-attach-user-tags option indicates that the backup plan's user tags are to be attached to the backup snapshot. Setting the --plan-copy-user-tags option to false indicates that the source volume's user tags are not copied to the backup. The --plan-delete-after option indicates the maximum number of days that the backups are to be kept and the --plan-delete-over-count option defines the maximum number of recent backups to keep. The -plan-clone-policy-zones option specifies that after the backup snapshot is created and stored in Object Storage regionally, a full copy of the backup is stored in the us-south-1 region of the availability zone. The --plan-clone-policy-max-snapshots option changes the number of cached backups that are stored in the AZ to 4. The default value is 5.
-f, --force
: Force operation without confirmation.

Examples:

ibmcloud sl vs dns-sync 12345678 --a-record --ttl 3600

This command synchronizes an A record (IPv4 address) of virtual server instance with ID 12345678 to DNS server and sets the TTL of this A record to 3600.





 ibmcloud sl vs edit 

Edit a virtual server instance's details:

ibmcloud sl vs edit IDENTIFIER [OPTIONS]

Command options:

-D, --domain
: Domain portion of the FQDN.

-H, --hostname
: Host portion of the FQDN. example: server.

-g, --tag
: Tags to set or empty string to remove all.

-u, --userdata
: User defined metadata string.

-F, --userfile
: Read user data from file.

--public-speed
: Public port speed, options are: 0,10,100,1000,10000.

--private-speed
: Private port speed, options are: 0,10,100,1000,10000.

Examples:

ibmcloud sl vs edit 12345678 -D ibm.com -H myapp --tag testcli --public-speed 1000

This command updates the virtual server instance with ID 12345678, and sets its domain to "ibm.com", host name to "myapp", and tag to "testcli".





 ibmcloud sl vs host-create 

Create a host for dedicated virtual servers:

ibmcloud sl vs host-create [OPTIONS]

Command options:

-H, --hostname
: Required. Host portion of the FQDN.

-D, --domain
: Required. Domain portion of the FQDN.

-d, --datacenter
: Required. Datacenter shortname.

-s, --size
DELETE Bucket CORS Deletes any CORS (cross-origin resource sharing) configuration set on a bucket. 
 GET Bucket Lists objects in a bucket. Limited to listing 1,000 objects at a time. 
 GET Bucket CORS Retrieves any CORS configuration set on a bucket. 
 HEAD Bucket Retrieves a bucket's headers. 
 GET Multipart Uploads Lists multipart uploads that aren't completed or canceled. 
 PUT Bucket Buckets have naming restrictions. Accounts are limited to 100 buckets. 
 PUT Bucket CORS Creates a CORS configuration for a bucket. 







 Object operations 

These operations create, delete, get information about, and control behavior of objects.



 Object operation Note 

 DELETE Object Deletes an object from a bucket. 
 DELETE Batch Deletes many objects from a bucket with one operation. 
 GET Object Retrieves an object from a bucket. 
 HEAD Object Retrieves an object's headers. 
 OPTIONS Object Checks CORS configuration to see whether a specific request can be sent. 
 PUT Object Adds an object to a bucket. 
 PUT Object (Copy) Creates a copy of an object. 
 Begin Multipart Upload Creates an upload ID for a set of parts to be uploaded. 
 Upload Part Uploads a part of an object that is associated with an upload ID. 
 Upload Part (Copy) Uploads a part of an existing object that is associated with an upload ID. 
 Complete Multipart Upload Assembles an object from parts that are associated with an upload ID. 
 Cancel Multipart Upload Cancels upload and deletes outstanding parts that are associated with an upload ID. 
 List Parts Returns a list of parts that are associated with an upload ID 



Some additional operations, such as tagging and versioning, are supported in private cloud implementations of Object Storage, but not in public or dedicated clouds currently. More information custom Object Storage solutions can be found at [ibm.com](https://www.ibm.com/cloud/object-storage).
ibmcloud resource search 'fullyQualifiedDomainName:MyVM _objectType:SoftLayer_Virtual_Guest' -p classic-infrastructure

Take a note of the ID, which is a string similar to 48373549.

To attach the tag, run the following command:

ibmcloud resource tag-attach --tag-names MyTag --resource-id 48373549 --resource-type SoftLayer_Virtual_Guest
* To attach the access management tag project:myproject, that you previously created, to an instance of IBM Cloud Object Storage called Project data, run the following command:

ibmcloud resource tag-attach --tag-names "project:myproject" --resource-name Project data -—tag-type access









 ibmcloud resource tag-detach 

Detaching one or more tags from a resource:

ibmcloud resource tag-detach --tag-names TAG_NAMES (--resource-name NAME | --resource-id RESOURCE_ID ) [--resource-type RESOURCE_TYPE] [--tag-type TAG_TYPE] [--account-id ACCOUNT_ID]



 Command options 

--tag-names value
: Comma-separated list of tag names.

--resource-name value
: Name of the resource on which the tags should be attached.

--resource-id value
: CRN of the resource on which the tags should be attached (for Classic Infrastructure resource, it is the ID of the resource).

--resource-type value
: Resource type on which the tags should be attached (required for Classic Infrastructure resource of type SoftLayer_Hardware, SoftLayer_Network_Application_Delivery_Controller, SoftLayer_Network_Subnet_IpAddress or SoftLayer_Network_Vlan only).

--tag-type value
: Type of the tag. Only allowed values are: user, service or access (default value : user).

--account-id value
: The ID of the account that owns the resources to be detached (required if tag-type is set to service).

-q, --quiet
: Suppress verbose output.





 Examples
[DevSecOps IBM Secrets Manager](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/devsecops-cc-toolchain-setup-SM.png)

Figure 4. DevSecOps IBM Secrets Manager

Multiple repositories must be configured during the guided setup, as described in the next sections.

For each repository, provide a URL to an existing IBM-hosted Git Repos and Issue Tracking repository that you own and that was specified during CI toolchain setup. The toolchain supports linking only to existing Git Repos and Issue Tracking repositories.





 Inventory 

The [inventory](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-inventory) repository records details of artifacts that are built by the CI toolchains.

Zoom

![DevSecOps inventory repository](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/devsecops-cc-toolchain-setup-inventory-repo.png)

Figure 5. DevSecOps inventory repository





 Target 

Provide details of the target environment to scan the deployed artifacts in this step. The pipeline runs a number of dynamic scans, and it is recommended to use your staging environment. IBM Cloud API key: The API key that you created and used during your CI toolchain setup. Optionally you can create a new key and store it in your preferred choice of secrets vault. Environment tag in your inventory: It is the [tag in your Inventory repository that reflects the state of your current deployed environment. This tag is the snapshot of current running application on target.

Zoom

!
Running a job 

After you create your job, you can run a job based on its definition, or you can run the job with overriding properties. Run your job from the console or with the CLI.

Each time your job runs, the latest version of your referenced container image is used for the job run, unless a tag is specified for the image. If a tag is specified for the image, then the tagged image is used for the job run.

Submitted batch jobs are run in parallel, if possible. If the number or size of the submitted jobs exceeds the configured quota limits, such as maximum number of running instances, then Code Engine queues the jobs and delays running them until enough jobs finish. For more information about quotas and limits for jobs, including memory and CPU, see [Limits and quotas for Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-limits).

Job runs that are created by subscriptions are deleted after 10 minutes. For more information about subscriptions, see [Getting started with subscriptions](https://cloud.ibm.com/docs/codeengine?topic=codeengine-subscribing-events).



 Running a job from the console 

When you create a job, you can run it immediately. However, you can submit and resubmit a job at any time. You can also submit or resubmit a job that you previously created.



1. Open the [Code Engine](https://cloud.ibm.com/codeengine/overview) console.
2. Select Projects from the navigation menu.
3. Select a project as the current context.
4. From the Overview page, select Jobs from the Summary section or select Jobs from the navigation menu.
5. Click the name of your job to open the configuration.
6. Click Submit job to open the Submit job dialog. Review and optionally change default configuration values such as instances, CPU, memory, number of job retries, and job timeout.
(https://cloud.ibm.com/docs-content/v1/content/f16b1f78a92498247223b337bd9303c2758b9ba8/discovery-data/images/gs-sample-enrichments.png)

Figure 5. Enrichments page of the Sample project

The following enrichments are applied to the sample collection:

Entities
: Recognizes proper nouns such as people, cities, and organizations that are mentioned in the content.

Part of Speech
: Identifies the parts of speech (nouns and verbs, for example) in the content.

These enrichments are applied automatically to collections that are added to projects of the Document Retrieval type.
4. For the Entities v2 enrichment, click 1x Selected fields.

A list of available fields is displayed and the text field is selected. This selection means that the Entities enrichment was applied to content that was indexed and added to a field named text when documents from the collection were processed.

Zoom

![Shows that the Entities enrichment is applied to the text field.](https://cloud.ibm.com/docs-content/v1/content/f16b1f78a92498247223b337bd9303c2758b9ba8/discovery-data/images/gs-entities-on-text.png)

Figure 6. Entities enrichment being applied to the text field
5. For the Part of Speech enrichment, click 1x Selected fields.

Again, you can see that the enrichment is applied to the text field.

From this page, you can apply new enrichments to your collection or change the fields where an enrichment is applied.

A powerful feature of Discovery is that you can add your own custom enrichments, such as dictionaries, patterns, and machine learning models. When you create custom enrichments, they are listed on this page also. You can manage where they are used from here.

For more information about custom enrichments, see [Adding domain-specific resources](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-domain).
ASV scanning of LBaaS data-plane appliances is solely a customer responsibility. IBM does not use ASVs to scan data-plane appliances because these scans can negatively impact customer workload functions and performance.
* What is a snapshot?

Snapshots are a point-in-time copy of your Block Storage for VPC boot or data volume that you manually create. To create a snapshot, the original volume must be attached to a running virtual server instance. The first snapshot is a full backup of the volume. Subsequent snapshots of the same volume record only the changes since the last snapshot. You can access a snapshot of a boot volume and use it to provision a new boot volume. You can create a data volume from a snapshot (called restoring a volume) and attach it to an instance. Snapshots are persistent; they have a lifecycle that is independent from the original volume.
* What is a backup snapshot?

Backup snapshots, also called backups, are scheduled snapshots that are created by using the Backup for VPC service. For more information, see [Backup for VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-backup-service-about).
* What is a bootable snapshot?

A bootable snapshot is a copy of a boot volume. You can use this snapshot to create another boot volume when you provision a new instance.
* What is a fast restore snapshot?

A [fast restore snapshot](https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-restore&interface=uisnapshots-vpc-use-fast-restore) is a clone of a snapshot that is stored within one or more zones of a VPC region. The original snapshot is stored in IBM Cloud Object Storage. When you perform a restore, data can be restored faster from a clone than from the snapshot in Object Storage.
* How many snapshots can I take?

You can take up to 750 snapshots per volume in a region. Deleting snapshots from this quota makes space for more snapshots.
Therefore, you aren’t given the option to choose one when you create it from the catalog. And, it can’t be assigned to any other resource group.
* What is an IAM access policy?

An IAM access policy is how users, services IDs, trusted profiles, and access groups in an account are given permission to work with a specific IAM-enabled service or resource instance, manage a resource group, or complete account management tasks. Each IAM access policy is made of a subject, target, and role. A subject is the who that has the access. The target is what the subject can have access to. And, the role, whether it is a platform or service role depending on the context of the selected target, defines what level of access the subject has on the target.

A subject is a user, service ID, trusted profile, or access group. A target can be a service in the account, a resource group in the account, a specific resource instance or type, or an account management service. And, the roles that are provided as choices depend on your selected target. Some services have service-specific roles that are defined, and some use platform roles only. To understand this concept visually, check out the following graphic with an outline of the options for creating an IAM policy:

![Creating IAM policies](https://cloud.ibm.com/docs/images/IAM.svg)

Figure 1. How IAM access policies are created by using a subject, target, and role
* How do I find out what I have access to?

In the IBM Cloud console, go to Manage > Access (IAM), and select your name on the Users page. Then, depending on the access you're looking for, open the different tabs:



* To determine what access you have through the access groups you are assigned, select Access and view the Access groups table.
* To see IAM access policies that are assigned to you, select Access and view the Access policies table.



* What actions are mapped to each IAM role?

When you invite a new user or assign a user IAM access, you can view the actions that are associated with each role.
Therefore, you aren’t given the option to choose one when you create it from the catalog. And, it can’t be assigned to any other resource group.
* What is an IAM access policy?

An IAM access policy is how users, services IDs, trusted profiles, and access groups in an account are given permission to work with a specific IAM-enabled service or resource instance, manage a resource group, or complete account management tasks. Each IAM access policy is made of a subject, target, and role. A subject is the who that has the access. The target is what the subject can have access to. And, the role, whether it is a platform or service role depending on the context of the selected target, defines what level of access the subject has on the target.

A subject is a user, service ID, trusted profile, or access group. A target can be a service in the account, a resource group in the account, a specific resource instance or type, or an account management service. And, the roles that are provided as choices depend on your selected target. Some services have service-specific roles that are defined, and some use platform roles only. To understand this concept visually, check out the following graphic with an outline of the options for creating an IAM policy:

![Creating IAM policies](https://cloud.ibm.com/images/IAM.svg)

Figure 1. How IAM access policies are created by using a subject, target, and role
* How do I find out what I have access to?

In the IBM Cloud console, go to Manage > Access (IAM), and select your name on the Users page. Then, depending on the access you're looking for, open the different tabs:



* To determine what access you have through the access groups you are assigned, select Access and view the Access groups table.
* To see IAM access policies that are assigned to you, select Access and view the Access policies table.



* What actions are mapped to each IAM role?

When you invite a new user or assign a user IAM access, you can view the actions that are associated with each role.
* If the network is to be stretched over the public internet or a VPN (on an alternative path), the L2C VM in vCenter Server requires an IP address. The remote IP address is required to configure the Layer 2 concentrator.
* If multiple Layer 2 concentrators are wanted, each must have an IP address on-premises and in the cloud.









 Pre-deployment planning 

Much of the time that is spent in deploying HCX is in the pre-deployment stage. It's typical for information systems migration projects to take months and even years to complete. However, HCX allows for migration to take a short time and for the network connectivity to the cloud to start immediately after deployment.

Since the deployment of HCX for an enterprise-level customer typically involves security, network, storage, and vSphere infrastructure teams, it makes sense to involve these teams in the POC if possible. Effective project management and early inclusion of stake holders, is critical to ensure the speed of deployment and operation of HCX is realized.





 Avoiding analysis paralysis 

Many of the hurdles and time that migration of a virtual machine (VM) or group of VMs takes are because parts of the application environment need to be modified. Also, the design of those changes and the scheduling of the downtime that is needed to make those changes can be complicated. After these changes are made, the migration becomes difficult to revert, further adding to analysis paralysis. Trying to capture all aspects of the migration, coordinating across teams, and changing key stake holders can delay the project.

HCX allows for cross vSphere instance migration of a VM or group of VMs that represent a partial or complete composite application, without any modifications to the application. Therefore, backing out of a migration means moving the VMs back or restretching the networks. As a result, you do not need a large part of migration planning and some parallelism in the planning process might occur. After you select the applications to move and create a high-level network design, the applications can begin migration with minimal configuration on the cloud instance while the final network connectivity and design is worked out.





 Stretched networks 

The network stretch components of the HCX fleet are stable.
This approach can be taken regardless of whether your service instance has any recovery crypto units. Using this approach, you run a series of commands to generate signature keys and master key parts, add administrators, set the signature thresholds, and load the master key registers. For more information, see [Initializing service instances by using key part files](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-initialize-hsm).

You need to be assigned the appropriate role to perform TKE CLI plug-in operations. For more information about the available service access roles, see [Service access roles](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-manage-accessservice-access-roles).

For a complete list of commands available in the TKE CLI plug-in, see [IBM Cloud Trusted Key Entry CLI plug-in reference](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-cli-plugin-hpcs-cli-plugintke-cli-plugin).





 Understanding operational crypto units 

Operational crypto units are used to manage encryption keys and perform cryptographic operations. Operational crypto units are the crypto units that you send API requests to. When you create a service instance, the number of crypto units that you specify is the number of operational crypto units. Operational crypto units are located in different availability zones of the same region where your instance resides.





 Understanding recovery crypto units 

Two recovery units are automatically assigned to your service instance without extra costs. One recovery unit is allocated in the same region as the operational crypto units, and the other is allocated in a backup region. When you run the ibmcloud tke auto-init or ibmcloud tke auto-mk-rotate command, a random master key value is generated in one of the recovery crypto units and then securely exported to the other crypto units (including failover crypto units if any) for the service instance.

The sole purpose of the recovery crypto units is to save a backup copy of the master key value.