vania-janet/multiturn-rag-retrieval-data huggingface dataset:
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. The recovery crypto units are not used when running operational workloads. If the current master key value is lost or destroyed, you can recover the master key value from either of the recovery crypto units by using the ibmcloud tke auto-mk-recover command. This command copies the value in the current master key register of a recovery crypto unit to the current master key register of other crypto units.

Currently, only the us-south and us-east regions are enabled with the recovery crypto units, which means, when a service instance is provisioned in either region, you are by default enabled with the option to back up your master keys in the recovery crypto units located in both regions. For more information about supported regions, see [Regions and locations](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-regions).

For detailed instructions on recovering the master key, see [Recovering a master key from a recovery crypto unit](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-uko-recover-master-key-recovery-crypto-unit).







 Initializing service instances by using key part files 

You can also initialize your service instance by using master key parts that you create and store in files on your local workstation. You can use this approach regardless of whether or not your service instance includes recovery crypto units. In this case, the workstation key files serve as a backup copy of your master key value. To complete the initialization in this approach, you also need to use the IBM Cloud TKE CLI plug-in.



 Understanding master key parts 

In this approach, the master key is composed of several master key parts that you need to use the TKE CLI plug-in to create.
Why do I get a manifest list invalid error? 

When you try to tag your manifest list or OCI Image Index in IBM Cloud® Container Registry, you get a manifest list invalid error.

 What’s happening 

You get the following manifest list invalid error when you try to [tag](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_tag) your [manifest](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_manifest) list or OCI Image Index in IBM Cloud Container Registry: The manifest list or OCI index that you are tagging references an image that doesn't exist.

 Why it’s happening 

Manifest lists and OCI Image Indexes contain a list of references to different images, where each image is for a different architecture. When you tag a manifest list or OCI Image Index, Container Registry tries to copy the referenced images. When you get this error message, it indicates that one of those referenced images was not found in the registry.

 How to fix it 

To understand how to fix this issue, you must work out what images are referenced in the manifest list or OCI Image Index by running the following command:

ibmcloud cr manifest-inspect <source_image>

The output of which is similar to this output:

{
"schemaVersion": 2,
"mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
"manifests": [
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 528,
"digest": "sha256:865b0c35e6da393b8e80b7e3799f777572399a4cff047eb02a81fa6e7a48ed4b",
"platform": {
"architecture": "amd64",
"os": "linux"
}
},
{
[Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/icons/checkmark-icon.svg) 
 [Aspera high-speed transfer](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-sdk-aboutsdk-about-aspera) ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/icons/checkmark-icon.svg) ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/icons/checkmark-icon.svg) 





 IAM API key support 

Allows for creating clients with an [API key](https://cloud.ibm.com/docs/account?topic=account-iamoverviewiamoverview) instead of a [pair of Access and Secret](https://cloud.ibm.com/docs/services/cloud-object-storage/hmac?topic=cloud-object-storage-uhc-hmac-credentials-main) keys.
Token management is handled automatically, and tokens are automatically refreshed during long-running operations.





 Managed multipart uploads 

Using a TransferManager class, the SDK handles all the necessary logic for uploading objects in parallel parts.





 Managed multipart downloads 

Using a TransferManager class, the SDK handles all the necessary logic for downloading objects in parallel parts.





 Extended bucket listing 

This extension to the S3 API returns a list of buckets with their LocationConstraint.
All buckets in a service instance are always returned on a list request, not just the subset that is located in the region of the target endpoint. This API is useful for finding where a bucket is located.





 Version 2 object listing 

Version 2 listing allows for more powerful scoping of object listings.





 Key Protect
[Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/icons/checkmark-icon.svg) 
 [Aspera high-speed transfer](https://cloud.ibm.com/docs/cloud-object-storage/basics?topic=cloud-object-storage-sdk-aboutsdk-about-aspera) ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/icons/checkmark-icon.svg) ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/icons/checkmark-icon.svg) 





 IAM API key support 

Allows for creating clients with an [API key](https://cloud.ibm.com/docs/account?topic=account-iamoverviewiamoverview) instead of a [pair of Access and Secret](https://cloud.ibm.com/docs/services/cloud-object-storage/hmac?topic=cloud-object-storage-uhc-hmac-credentials-main) keys.
Token management is handled automatically, and tokens are automatically refreshed during long-running operations.





 Managed multipart uploads 

Using a TransferManager class, the SDK handles all the necessary logic for uploading objects in parallel parts.





 Managed multipart downloads 

Using a TransferManager class, the SDK handles all the necessary logic for downloading objects in parallel parts.





 Extended bucket listing 

This extension to the S3 API returns a list of buckets with their LocationConstraint.
All buckets in a service instance are always returned on a list request, not just the subset that is located in the region of the target endpoint. This API is useful for finding where a bucket is located.





 Version 2 object listing 

Version 2 listing allows for more powerful scoping of object listings.





 Key Protect
Generate administrator signature keys separately on two EP11 smart cards and copy them to other two backup smart cards.

The contents of an EP11 smart card can be copied to another EP11 smart card that was created in the same smart card zone by using the Trusted Key Entry application. On the Smart card tab, click Copy smart card, and follow the prompts.
* Create two EP11 smart cards and two backup EP11 smart cards to store two master key parts, or create three EP11 smart cards and three backup EP11 smart cards to store three master key parts. Generate EP11 master key parts separately on two or three smart cards, depending on the number of key parts when you load your master key. Copy each key part value to a backup EP11 smart card.



For how to calculate the number of smart cards needed, see [FAQ: Are there any recommendations on how to set up smart cards?](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-faq-provisioning-operationsfaq-smart-card-setup)
* For greater security, generate administrator signature keys on more EP11 smart cards and set the signature thresholds in your crypto units to a value greater than one. You can install up to eight administrators in your crypto units and specify that up to eight signatures are required for some administrative commands.







 Understanding smart card readers 

A smart card reader is a device that attaches to a workstation and allows the workstation to communicate with a smart card. To access a smart card, the smart card must be inserted in the smart card reader. Most smart card operations require the smart card PIN to be entered on the smart card reader PIN pad.

A driver for the smart card reader must be installed on the workstation before the smart card reader can be used. For more information, see [Installing the smart card reader driver](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-prepare-management-utilitiesinstall-smart-card-reader-driver).

The TKE application uses smart card reader 1 to hold a smart card with a signature key, and uses smart card reader 2 to hold smart cards that contain master key parts.
To assign a different name to a referenced key, use the format NAME:NEW_NAME=KEY_A. For example, to add an environment variable named myKey for a single key key1 in a secret that is named secretName, use the value secretName:myKey=key1.



This value is optional.

--env-from-secret-rm, --env-sec-rm
: Remove environment variable references to full secrets by using the secret name. To remove individual key references to secrets, use the --env-rm option. This option can be specified multiple times. This value is optional.

--env-rm
: Remove environment variable references to the key of a key-value pair in a configmap or secret. To remove individual key references and literal values, specify the name of the key. This option can be specified multiple times. This value is optional.

--ephemeral-storage, --es
: The amount of ephemeral storage to set for runs of the job. Use M for megabytes or G for gigabytes. This value is optional.

--force, -f
: Do not verify the existence of specified configmap and secret references. Configmap references are specified with the --env-from-configmap option. Secret references are specified with the --env-from-secret or --registry-secret options. This value is optional. The default value is false.

--image, -i
: The name of the image that is used for runs of the job. The format is REGISTRY/NAMESPACE/REPOSITORY:TAG where REGISTRY and TAG are optional. If REGISTRY is not specified, the default is docker.io. If TAG is not specified, the default is latest. This value is optional.

--instances, --is
: Specifies the number of instances that are used for runs of the job. When you use this option, the system converts to array indices. For example, if you specify instances of 5, the system converts to array-indices of 0 - 4.
When you add the Filter element in the configuration, you must also add the following elements: DeleteMarkerReplication, Status, and Priority.



 Header Type Description 

 Content-MD5 String Required: The base64 encoded 128-bit MD5 hash of the payload, which is used as an integrity check to ensure that the payload wasn't altered in transit. 



The body of the request must contain an XML block with the following schema:



 Element Type Children Ancestor Constraint 

 ReplicationConfiguration Container Rule None Limit 1. 
 Rule Container ID, Status, Filter, DeleteMarkerReplication, Destination, Priority ReplicationConfiguration Limit 1000. 
 ID String None Rule Must consist of (a-z,A-Z0-9) and the following symbols: !_.'()- 
 Destination Container Bucket Rule Limit 1. 
 Bucket String None Destination The CRN of the target bucket. 
 Priority Integer None Rule A priority is associated with each rule. There may be cases where multiple rules may be applicable to an object that is uploaded. In these situations, object storage will apply the applicable rule with the higher priority when replicating that object. Thus only a single replication rule can be applied to any object, irrespective of how many rules in the replication policy may be a match for the object. Note that the higher the number, the higher the priority. 
 Status String None Rule Specifies whether the rule is enabled. Valid values are Enabled or Disabled. 
 DeleteMarkerReplication Container Status Rule Limit 1. 
 Status String None DeleteMarkerReplication Specifies whether Object storage replicates delete markers. Valid values are Enabled or Disabled. 
 Filter String Prefix, Tag, AND Rule A filter that identifies the subset of objects to which the replication rule applies. A Filter must specify exactly one Prefix, Tag, or an And child element. 
 Prefix String None Filter An object key name prefix that identifies the subset of objects to which the rule applies. 
 Tag String None Filter A container for specifying a tag key and value. The rule applies only to objects that have the tag in their tag set. 
 And String None Filter A container for specifying rule filters. The filters determine the subset of objects to which the rule applies.
terraform init
3. Provision the resources from the main.tf file. For more information, see [Provisioning Infrastructure with Terraform](https://www.terraform.io/cli/run).



1. Run terraform plan to generate a Terraform execution plan to preview the proposed actions.

terraform plan
2. Run terraform apply to create the resources that are defined in the plan.

terraform apply









 Attaching tags to a service ID in the console 

To add a tag to a service ID, complete the following steps:



1. Choose to attach an access management tag or a user tag.



* If you want to attach an access management tag, you must first create the tag. For more information, see [Creating tags](https://cloud.ibm.com/docs/account?topic=account-tag&interface=uicreate).
* If you want to attach a user tag, you don't need to create the user tag to attach it to resources or service IDs. Attaching the tag also creates it.



2. Go to Manage > Access (IAM) > Service IDs.
3. Select the service ID that you want to tag.
4. Click Add tag![Edit icon](https://cloud.ibm.com/docs-content/v1/content/4d8c6eec891cff72b666dc24bd3211810c77fb42/icons/edit-tagging.svg).
5. Enter the name of the tag, and press Enter.
6. Click Save.



When you tag a service ID, all policies that have resources that are scoped to your access management tag include access to this service ID.





 Attaching tags to a service ID by using the CLI 

The allowed values for the tag_type query parameter are: user for user tags and access for access management tags. The following example shows how to attach an access management tag that is called project:myproject to a service ID.

To add a tag to a service ID, complete the following steps:
If user-ID-based authentication is used, supply the username.
6. If certificate-based authentication is used, supply the common name of your client certificate.

To view the common name of your client certificate, use the OpenSSL command openssl x509 -noout -text -in your_client_certificate_file in the subject section.



* How do I assign the VPN client role using IAM access management tags in the API?

When you manage user access using access management tags on a client-to-site VPN and enable the UserId and Passcode mode for Client Authentication, you must attach the VPN Client role with an access tag. Otherwise, the VPN client cannot connect to the VPN server. For more information, see [Granting users access to tag IAM-enabled resources by using the API](https://cloud.ibm.com/docs/account?topic=account-access&interface=apiiam-managed-api) and set the role_id to crn:v1:bluemix:public:is::::serviceRole:VPNClient to grant access.
* When I create a VPN gateway, can I create VPN connections at the same time?

In the IBM Cloud console, you can create the gateway and a connection at the same time. If you use the API or CLI, VPN connections must be created after the VPN gateway is created.
* If I delete a VPN gateway with attached VPN connections, what happens to the connections?

The VPN connections are deleted along with the VPN gateway.
* Are IKE or IPsec policies deleted if I delete a VPN gateway or VPN connection?

No, IKE and IPsec policies can apply to multiple connections.
* What happens to a VPN gateway if I try to delete the subnet that the gateway is on?

The subnet cannot be deleted if any virtual server instances are present, including the VPN gateway.
* Are there default IKE and IPsec policies?

When you create a VPN connection without referencing a policy ID (IKE or IPsec), auto-negotiation is used.
* Why do I need to choose a subnet during VPN gateway provisioning?
Forced redeployment of an application 

Sometimes, a running application in an environment crashes or behaves abnormally due to changes in the infrastructure configuration and requires a redeployment. In such cases, you can use the continuous deployment pipeline to deploy the existing state of the inventory to the target environment by setting a new environment variable for the continuous deployment pipeline.

Set the force-redeploy environment variable with the value as true while the Manual CD pipeline run is triggered.

During redeployment, the branch in your inventory repository that corresponds to the environment (for example prod, stage) does not contain any new items, and the <target-environment>_latest tag points to the current commit. The presence of the force-redeploy flag tells the CD Pipeline to ignore checking any new changes and proceed with the current stage of the inventory.

The summary of steps that are followed by the CD Pipeline for forced redeployment include:



1.  The CD Pipeline starts and tags the current commit with the pipeline run ID.
2.  The pipeline picks up the content of the corresponding environment branch from that tag.
3.  The pipeline calculates the deployment delta between the current commit and the contents of the <target-environment>_latest tag. Because the content is identical in this case, the delta is empty. The setting force-redeploy makes it possible for the pipeline to continue.
4.  A successful deployment concludes by attaching the <target-environment>_latest tag to the commit that you work with. Because the content is identical, no changes are present.
As the number of backups grow, a good naming convention can make them more identifiable.







 Best practices for user actions 



* Organize tags that you apply to volumes and specify in backup policies. Ensure that multiple policies aren't using the same tags for target resources because that might trigger duplicate volume backups. You need only one tag to match to trigger a backup.
* Determine what tags are already assigned to a volume from the list of Block Storage for VPC volumes. If a volume has multiple tags, make sure that the tags are not triggering duplicate backups for multiple policies.
* Decide how you prefer to add tags. You can create tags for target resources in your backup policy first and then, apply them to volumes. Or, you can specify tags that are applied to the volume already in the backup policy. If you choose to use existing tags, be aware that the same tags might be attached other volumes that you might not want to back up from this policy.
* Decide whether creating one or multiple backup plans suits your needs. For example, multiple plans can trigger backups at different intervals. You might want to back up some volumes monthly, others more frequently in a daily or weekly plan.







 Administrator best practices 



* Determine which users can have permission to add tags to target resources. For more information, see [Granting users access to tag resources](https://cloud.ibm.com/docs/account?topic=account-access).







 Applying best practices 

Apply best practices when you create a backup strategy. The following example illustrates how you might set up a backup solution.

Assume you have 10 volumes that are spread across different departments. Some volumes contain time-critical information that you need to back up hourly. Other volumes contain archived information that doesn't change much, so you'd prefer to back them up weekly. You can create four backup plans per policy. Your solution might look like this:

Create a backup policy with an hourly backup plan for the time-critical volumes:



* When you create the policy, create a tag for the target volumes (for example, hourly-finance). Provide a policy name that reflects the interval and type of data. It can help organize policies in the list and the volumes that are associated with them.
The contents of an EP11 smart card can be copied to another EP11 smart card that was created in the same smart card zone by using the Trusted Key Entry application. On the Smart card tab, click Copy smart card, and follow the prompts.
* Create four or six EP11 smart cards to store master key parts. Generate EP11 master key parts separately on two or three smart cards, depending on the number of key parts when you load your master key. Copy each key part value to a backup EP11 smart card.



For how to calculate the number of smart cards needed, see [FAQ: Are there any recommendations on how to set up smart cards?](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-faq-provisioning-operationsfaq-smart-card-setup).
* For greater security, generate administrator signature keys on more EP11 smart cards and set the signature thresholds in your crypto units to a value greater than one. You can install up to eight administrators in your crypto units and specify that up to eight signatures are required for some administrative commands.







 Understanding smart card readers 

A smart card reader is a device that attaches to a workstation and allows the workstation to communicate with a smart card. To access a smart card, the smart card must be inserted in the smart card reader. Most smart card operations require the smart card PIN to be entered on the smart card reader PIN pad.

A driver for the smart card reader must be installed on the workstation before the smart card reader can be used. For more information, see [Installing the smart card reader driver](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-prepare-management-utilitiesinstall-smart-card-reader-driver).

The TKE application uses smart card reader 1 to hold a smart card with a signature key, and uses smart card reader 2 to hold smart cards that contain master key parts.

After a smart card that contains a valid signature key is inserted in smart card reader 1 and the PIN is entered, the smart card can be used to sign multiple commands, without needing to enter the PIN again.
Creating selector expressions 

In general, whenever you have an operator that takes an argument, that argument can itself be another operator with arguments of its own. This expansion enables more complex selector expressions.

Combination or array logical operators, such as $regex, can result in a full database scan when you use indexes of type JSON, resulting in poor performance. Only equality operators, such as $eq, $gt, $gte, $lt, and $lte (but not $ne), enable index lookups. To ensure that indexes are used effectively, analyze the [explain plan](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-creating-selector-expressionsexplain-plans) for each query.

Most selector expressions work exactly as you would expect for the operator. The matching algorithms that are used by the $regex operator are currently based on the [Perl Compatible Regular Expression (PCRE) library](https://en.wikipedia.org/wiki/Perl_Compatible_Regular_Expressions). However, not all of the PCRE library is implemented. Additionally, some parts of the $regex operator go beyond what PCRE offers. For more information about what is implemented, see the [Erlang Regular Expression](https://www.erlang.org/doc/man/re.html) information.



 Sort syntax 

The sort field contains a list of field name and direction pairs, expressed as a basic array. The first field name and direction pair are the topmost-level of sort. The second pair, if provided, is the next level of sort.

The sort field can be any field. Use dotted notation if needed for subfields.

The direction value is asc for ascending, and desc for descending.

If you exclude the direction value, the default asc is used.

See the following example of simple sort syntax:

[
{
"fieldName1": "desc"
},
{
"fieldName2": "desc"
}
]

See the following example of simple sort, assuming default direction of "ascending" for both fields:

[