vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Can I initialize my service instance through the TKE CLI plug-in by using a proxy? 

Yes, if the proxy is configured for HTTPS port 443. You can add an entry to the local hostname mapping of your workstation with the TKE CLI, for example, in /etc/hosts. In this host mapping entry, map the TKE API endpoint tke.<region>.hs-crypto.cloud.ibm.com to your proxy. For example, for an instance in Frankfurt the URL is tke.eu-de.hs-crypto.cloud.ibm.com.





 Are there any recommendations on how to set up smart cards? 

It is suggested that each master key part is created on a separate EP11 smart card and is assigned to a different person. Backup copies of all smart cards need to be created and stored in a safe place. It is suggested that you order 10 or 12 smart cards and initialize them this way:



* Create a certificate authority (CA) smart card and a backup certificate authority smart card.
* Create two EP11 smart cards and two backup EP11 smart cards to store two administrator signature keys. Generate administrator signature keys separately on two EP11 smart cards and copy them to other two backup smart cards.
* 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 calculating the number of smart cards needed, you can refer to the following formulas:



Table 1. Formulas for calculating smart cards number

 Assumptions Formula
Step 3: Set the quorum authentication thresholds to exit imprint mode in the target crypto unit 

A crypto unit in imprint mode isn't considered secure. You can't run most of the administrative commands, such as loading the new master key register, in imprint mode.

After you add one or more crypto unit administrators, exit imprint mode by using the command:

ibmcloud tke cryptounit-thrhld-set

When prompted, enter values for the signature threshold and revocation signature threshold. The signature threshold controls how many signatures are required to execute most administrative commands. The revocation signature threshold controls how many signatures are required to remove an administrator after you have left imprint mode. Some commands require only one signature, regardless of how the signature threshold is set.

The signature threshold values must be numbers between one and eight. The signature threshold and revocation signature threshold can be different. Setting the signature thresholds to a value greater than one is a way to enforce [quorum authentication](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-understand-conceptsquorum-authenticaion-concept) for sensitive operations, including committing a master key register, changing the signature thresholds, and adding or removing administrators after the crypto unit exits imprint mode.

The command to exit imprint mode must be signed by as many administrators as specified by the new signature threshold value. After crypto units leave imprint mode, all commands to the crypto unit must be signed. After the crypto unit exits imprint mode, you can still change the signature thresholds on the crypto unit by using the cryptounit-thrhld-set command. To display the current signature threshold values, run the ibmcloud tke cryptounit-thrhlds command.





 Step 4: Create a set of master key parts to use 

Each master key part is saved in a password-protected file on the workstation.

You must create at least two master key parts. For security considerations, a maximum of three master key parts can be used and each key part can be owned by a different person. The key part owner needs to be the only person who knows the password that is associated with the key part file.
For example, to set the prefix for all variable names of keys in secret secretName to CUSTOM_, use the value CUSTOM_=secretName. If the secret secretName contains KEY_A, the environment variable name is CUSTOM_KEY_A.
* To add environment variables for individual keys, use the format NAME:KEY_A,KEY_B. For example, to add an environment variable for a single key key1 in a secret that is named secretName, use the value secretName:key1. 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.

--ephemeral-storage, --es
: The amount of ephemeral storage to set for the instance of the application. 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 or --mount-configmap options. Secret references are specified with the --env-from-secret, --mount-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 this application. 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. The image option is required if the --build-source option is not specified. This value is optional.

--max-scale, --max, --maxscale
: The maximum number of instances that can be used for this application. If you set this value to 0, the application scales as needed. The application scaling is limited only by the instances per the resource quota for the project of your application.
[Maven build with custom image](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/custom-image-maven-build.png)

Figure 1. Maven build with custom image



 Specifying the Docker image name 

The Docker image name in custom Docker image jobs is designed to work in the same way that image names work with the Docker CLI. The format of a Docker image name is: [repository][tag]. For example, for docker run maven:3.5.3-ibmjava, the Docker image name is maven:3.5.3-ibmjava, where maven is the repository and 3.5.3-ibmjava is the tag. There are no restrictions on the Docker image name that you can use; any valid docker image works.

If the Docker image name field is not completed, the standard pipeline base image is used.

By default, your repository on [Docker Hub](https://hub.docker.com/) is searched. If you use another Docker registry, such as IBM Cloud® Container Registry, you can use the full DNS name. You can also use the fully qualified name for images on Docker Hub. For example, registry.hub.docker.com/library/maven:3.5.3-ibmjava.

The tag for a Docker image is optional. If you do not specify a tag, by default it is set to latest. A default value of latest is just a tag name that the repository owner must manage. It does not mean that chronologically this Docker image is the latest image.

You can find a large community of repositories at Docker Hub. IBM hosts a number of public repositories that the IBM Cloud team uses at [https://hub.docker.com/u/ibmcom/](https://hub.docker.com/u/ibmcom/).
For more information, see [Resizing a virtual server instance](https://cloud.ibm.com/docs/vpc?topic=vpc-resizing-an-instance).





 Common use cases 



* Workload needs highest availability for critical application instances.



* Issue: Distributed application or database experiences an outage if any one of the application parts experience a failure.
* Solution: Use power spread placement group policy for independent power and network.



* Workload needs to optimize topology-aware applications.



* Issue: Modern database uses triple replication for redundancy therefore must make sure that performance for database components while also optimizing high availability for replicate parts of the database.
* Solution: Use power spread placement group policy to group database components on different power supplies.









 Limitations 



* The VPC must exist before you create a placement group. If the VPC isn't created before you create a placement group, you receive an error and the placement group isn't created.
* The quotas have a set limit and can't be adjusted. For more information about placement group quotas, see the placement group quotas section in [Quotas and service limits](https://cloud.ibm.com/docs/vpc?topic=vpc-quotasplacement-group-quotas).







 Restrictions 

The following are the restrictions for placement groups:



* The placement group placement strategy can't be modified after the placement group is created.
* The placement group must be deleted and created with a new placement strategy.
* A placement group can't be deleted if it is attached to one or more instances.



The following are the restrictions for instances that are attached to a placement group:



* An instance can be in only one placement group.
* Instances that are provisioned with placement group strategies do not work with dedicated hosts.
* After an instance is placed, the assigned placement of that instance does not change based on placement of other instances.
* After an instance is started, the associated placement group strategy can't be changed.
* Instances can't be removed from a placement group or assigned to a different placement group. Instances must be deleted to remove the instance from the placement group.
Return to the bucket configuration window or tab, and click on the Check permissions button again.



Now you'll create a replication rule.



1. Ensure the rule status radio button is set to Enabled.
2. Give the rule a name and a priority, as well as any prefix or tag filters that will limit the objects subject to the replication rule.
3. Click Done.







 Terminology 

Source bucket: The bucket for which a replication policy is configured. It is the source of replicated objects.

Target bucket: The bucket that is defined as the destination in the source bucket replication policy. It is the target of replicated objects. Also referred to as a 'destination' bucket.

Replica: The new object created in a target bucket as a result of a request made to a source bucket.





 What is replicated? 

New objects created via CopyObject, PutObject, or CompleteMultipartUpload will be replicated from the source bucket to the target bucket. The replicated objects will inherit the following metadata fields from the source object: Etag, Last Modified Time, Version ID, user-attributes, and Tags.

Delete markers will be replicated if configured by the replication policy.

Updates to a version's tags will be replicated from the source bucket to the target bucket.

The following are not replicated:



* Actions initiated by lifecycle events
* Objects written directly to archive
* Objects restored from an archive tier
* Objects encrypted via SSE-C
* Object ACLs
* Object-Lock state







 Using replication for business continuity and disaster recovery 

Replication can be used to provide continuity of service in the event of an outage:



* Ensure that the source and target buckets are in different locations.
* Verify that the latest versions of objects are in sync between both buckets. A tool such as [Rclone](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-rclone) (the rclone check command) can be useful for checking synchronicity from the command line.
The request must provide the token and a basic authorization header that contains the client ID and secret.

Example request:

POST /oauth/v4/<tenantID>/introspect HTTP/1.1
Host: us-south.appid.cloud.ibm.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic jdFlUaGlZUzAwTW0Tjk15TmpFMw==
Cache-Control: no-cache

token=XXXXX.YYYYY.ZZZZZ
2. The server checks the expiry and signature of the token and returns a JSON object that tells whether the token is active or inactive.

Example response:

{
"active": true
}







 Manually Validating Tokens 

You can validate your tokens locally by parsing the token, verifying the token signature, and validating the claims that are stored in the token.



1. Parse the tokens. The [JSON Web Token (JWT)](https://datatracker.ietf.org/doc/html/rfc7519) is a standard way of securely passing information. It consists of three main parts: Header, Payload, and Signature. They are base64URL encoded and separated by a dot(.). You can use any base64URL decoder available to parse the token. Alternatively, you can use any of the [libraries that are listed](https://jwt.io/libraries-io) to parse the token.

Example encoded token:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpPU0UiLCJraWQiOiJhMmszIn0
.eyJpc3MiOiJhcHBpZC1vYXV0aCIsImF1ZCI6ImFiYzEyMyIsImV4cCI6MTU2NDU2Nn0
.IycnAGUmMHzpTWbe-qaRsx0B4Zi-SVav710Fb_8CTCQvLrHX9d42WuCZ5bW
* In a staging environment, you might consider using a tag X.Y so auto-updates happen when a new patch is released.
* In a production environment, you can use the tag X.Y.Z so that auto-updates happen when a new vulnerability fix is released.
* For highly regulated environments, you should use the tag X.Y.Z-<date>.[hash]. Notice that you will have to check periodically for vulnerability fixes, patches, and minor version releases to keep the agent free of issues.



The logging agent auto-updates happen when you restart the logging pod. It is your responsibility to restart the pods periodically in order for agent updates to occur within the scope specified by the tag.





 Stable and latest tags (deprecated) 

For the V1 and V2 agent versions, you can also find the tags stable and latest. When you use any of these tags to configure the logging agent, notice that the logging agent will automatically update to the latest version of the agent.



* The tag latest refers to the most recent logging agent 1.Y image.
* The tag stable refers to the most recent logging agent 2.Y image.



The tags stable and latest will be deprecated in June 2021.





 Image versions 

The following table outlines the logging agent versions that are available to configure for a Kubernetes cluster:



Table 2. logging agent versions for Kubernetes clusters

 Kubernetes cluster logging agent V3 logging agent V2 logging agent V1 

 Standard Kubernetes cluster ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/f61dbc5d84bf0c89e477a05cab04c72f429e1b7a/log-analysis/images/checkmark-icon.svg) ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/f61dbc5d84bf0c89e477a05cab04c72f429e1b7a/log-analysis/images/checkmark-icon.svg) !
When one volume tag matches a backup policy tag for target resources, it triggers a backup of the volume contents. A backup policy defines a backup plan that schedules when backup snapshots are taken.

From the [volume details](https://cloud.ibm.com/docs/vpc?topic=vpc-viewing-block-storage&interface=uiview-vol-details-ui) page, you can view the backup policies that are applied to the volume and add user tags that are associated with a backup policy.



1. Go to the list of Block Storage for VPC volumes. In [IBM Cloud console)](https://cloud.ibm.com/login), go to menu icon ![menu icon](https://cloud.ibm.com/docs-content/v1/content/icons/icon_hamburger.svg) > VPC Infrastructure > Storage > Block storage volumes.
2. Locate the volume that you want and click the name link.
3. From the Block Storage for VPCdetails page, click the Backup policies tab.
4. Click Attach.
5. In the side panel, select a backup policy from the list of available policies, and then select the policy tags to apply to the volume. You can also view the plan details that can help you decide whether to use that policy.
6. Click Apply policy and tags. The backup policy shows in the list of backup policies that are associated with the volume.



When you go to the [backup policy page](https://cloud.ibm.com/docs/vpc?topic=vpc-backup-view-policies&interface=uibackup-view-vol-backup-policies), the volume for which you added tags shows up in the list of volumes.

For more information about creating backups, see [Creating a backup policy](https://cloud.ibm.com/docs/vpc?topic=vpc-backup-about). For more information about user tags, see [Working with tags](https://cloud.ibm.com/docs/account?topic=account-tag).







 Managing Block Storage for VPC from the CLI
Ledgers themselves contain two distinct, though related, parts: a world state which records the current value of any key (such as an asset), and a blockchain which contains a literal “chain of blocks” that contain the records of each transaction. Peers receive state updates in the form of new blocks from the ordering service. They then use the blocks and the world state to confirm (or commit) transactions, update the world state and add the log of transactions on the blockchain.

Ordering nodes form a Raft ordering cluster that comprises the ordering service of a channel. The ordering service literally “orders” transactions into blocks that are sent to peers to be committed to their ledgers. Each ordering node stores a copy of the blockchain portion of the channel ledger.

Channels are the place where organizations interact within a network. You cannot participate in a blockchain network without joining a channel. Channels can be used by members of the network to create logical separation between business applications and even to boost performance by limiting traffic. They can also be used by subsets of organizations in the consortium to transact privately and separate data.

Peers maintain a separate ledger for each channel that they join. Only organizations that are members of the channel can join their peers to the channel and receive ledger updates from the ordering service. As a result, each channel is bound to an ordering service, which stores the blockchain portion of every channel ledger that it maintains. Client applications submit transactions to the peers and ordering service of a given channel. These transactions are added to the transaction log within the blockchain and include a [read-write set](https://hyperledger-fabric.readthedocs.io/en/release-2.2/readwrite.html) that is used to update the key-value pairs in the world state.

If in-country data residency is a requirement, you need to consider the location of your peers and the ordering service, as well as your client applications. You also need to know the location of the peers that belong to other organizations on your channels.
Using CIDR notation 

You must not use an IP range outside of the ranges that are defined by [RFC 1918](https://tools.ietf.org/html/rfc1918) (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) for a subnet. The instances that are attached to that subnet might not be able to reach parts of the public internet.

If you are using an IP range outside of the ranges that are defined by [RFC 1918](https://tools.ietf.org/html/rfc1918) (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) for a subnet you must use IANA assigned IPs and GRE tunneling. For more information see [Generic Routing Encapsulation (GRE) tunneling](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-configuring-powergre-tunneling). PowerVS assigns IPs as Internal IP from the prefix 192.168.0.0/16 to your accounts for Public Network access. Once a public subnet is assigned, you cannot use those IPs for private networks.

The following networks are filtered out and are not accepted: 10.0.0.0/14, 10.200.0.0/14, 10.198.0.0/15, and 10.254.0.0/16.

The number after the slash represents the bit length of the subnet mask. As a result, the smaller the number after the slash, the more IP addresses you are allocating. The following table lists the number of available addresses in a subnet (based on its specified CIDR block size):



Table 2. Understanding CIDR notation caption

 CIDR block size Available IP addresses (WDC04,WDC06) Available IP addresses (non-WDC) 

 /22 1019 1021 
 /23 507 509 
 /25 123 125 
 /26 59 61 
 /27 27 29 
 /28 11 13
Currently, the Management Utilities support two or three master key parts to be loaded.



For added security, the two or three master key parts that are used to configure a service instance can be generated on separate EP11 smart cards that are assigned to different people. The signature key that is used to sign commands to the crypto module can be generated on a separate EP11 smart card. Three or four EP11 smart cards are then needed to configure a service instance.

It is also suggested to [create backup copies of all used smart cards](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-faq-provisioning-operationsfaq-smart-card-setup) and to save the backup smart cards in a secure place. For maximum security, 12 smart cards are needed, which includes backup smart cards:



* Two certificate authority smart cards
* Ten EP11 smart cards



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)
2. Contact your IBM Sales representative or your IBM Business Partner and provide the following information. If you need assist in finding an IBM Sales representative, you can reach out zcat@ibm.com.



* The total number of smart cards needed; minimum of two.
* Billing contact information, which includes the name, billing address, phone number, email address, and time zone.
* Shipping contact information, which includes the name, shipping address, phone number, email address, and time zone.



For more information about ordering smart cards through your IBM sales representatives or Business Partners, see [IBM® Hyper Protect Crypto Services hardware announcement](https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/6/897/ENUS122-116/index.html).







 Ordering smart card readers 

To order smart card readers, you have the following options:
When the worker nodes are ready, the worker node state changes to normal and the status changes to Ready. When the node status is Ready, you can then access the cluster. Note that even if the cluster is ready, some parts of the cluster that are used by other services, such as Ingress secrets or registry image pull secrets, might still be in process. Note that if you created your cluster with a private VLAN only, no Public IP addresses are assigned to your worker nodes.

ID Public IP Private IP Flavor State Status Zone Version
kube-blrs3b1d0p0p2f7haq0g-mycluster-default-000001f7 169.xx.xxx.xxx 10.xxx.xx.xxx u3c.2x4.encrypted normal Ready dal10 1.26.6_1526

Every worker node is assigned a unique worker node ID and domain name that must not be changed manually after the cluster is created. If you change the ID or domain name, the Red Hat OpenShift master cannot manage your cluster.
10. Optional: If you created your cluster in a [multizone metro location](https://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zoneszones-mz), you can [spread the default worker pool across zones](https://cloud.ibm.com/docs/openshift?topic=openshift-add_workersadd_zone) to increase the cluster's availability.
11. After your cluster is created, you can [begin working with your cluster by configuring your CLI session](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).



Your cluster is ready for your workloads! You might also want to [add a tag to your cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-add_workerscluster_tags), such as the team or billing department that uses the cluster, to help manage IBM Cloud resources.