vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For more information, see [deciding to enable customer-managed keys](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-managing_encryptionconsiderations_keys).





 Using a customer-managed key 

After a customer-managed key is enabled, the cluster operates as normal, but with the following additional capabilities.



 Preventing access to data 

To temporarily prevent access, disable your root key. As a consequence, Event Streams can no longer access the data because it can no longer access the key.

To remove access permanently, delete the key. However, you must take extreme caution because this operation is non-recoverable. You lose access to any data that is stored in your Event Streams instance. It is not possible to recover this data.

In both cases, the Event Streams instance shuts down and no longer accepts or processes connections. An activity tracker event is generated to report the action. For more information, see [Activity Tracker events](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-at_eventsevents).

The authorization is to be left in place between your Event Streams and the key management service instance at all times. While removing this authorization prevents Event Streams from future access to your data, already in-use data continues to be available for a period of time.

You are charged for your instance of Event Streams until you deprovision it using the IBM Cloud® console or CLI. These charges are still applied even if you chose to prevent access to your data.





 Restoring access to data 

Access can be restored only if the key was not deleted. To restore access, re-enable your root key. After a short period of initialization, your Event Streams instance is restarted and starts accepting connections again. All data is retained, subject to the normal retention limits configured in your instance.

An activity tracker event is generated to report the action. For more information, see [Activity Tracker events](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-at_eventsevents).





 Rotating the key
In the Include users section, specify which users to add to the group when it's created.
7. Click Create.







 Information about groups 



Table 1. The table lists group-related values and their definitions.

 Value Description 

 Name Specifies the name of the group. 
 Owner Specifies the database user who owns the group. 
 Default priority Specifies the workload management control that specifies the default priority for queries that are run by the users in this group. 
 Max priority Specifies the workload management control that specifies the maximum priority that a user in the group can assign to sessions or queries. 
 Password expiration Specifies when a group password expires. 
 Created on Specifies when the group was created. 







 Groups actions 

In the Groups list view, there is an overflow menu that lists the actions that can be taken on each group.



Table 1. The table lists group-related actions and their definitions.

 Value Description 

 Password expiration Set the time in days after which the password expires for the members of a group. 
 Assign owner Set the owner of the group. 
 Manage users Add or remove users from the group. 
 Rename Change the group name. 
 Admin privileges View and grant admin privileges. 
 Object privileges View and grant object privileges. 
 Remove Delete the group from the system. 







 Granting admin privileges to groups 

Group privileges dictate what actions can be taken by users who are a part of the group.



1. Go to Users and groups > Groups.
2. Select the group for which you want to grant admin privileges and select Admin privileges from the overflow menu.
In this view, you can see different admin privileges, which are already granted or that can be granted to the selected group.
Granting these privileges allows the users that belong to the group to do the actions that the privileges correspond to. Granting privileges on global database and global schema unlocks all the privileges to the user equivalent to an admin.
3. Click Edit.
4. Update, grant, or revoke object privileges by putting ticks in corresponding boxes.
5. Click Save.







 Granting object privileges to groups
Options:
--schedule-type TEXT Snapshot schedule [INTERVAL|HOURLY|DAILY|WEEKLY]
[required]
--retention-count TEXT Number of snapshots to retain [required]
--minute INTEGER Minute of the day when snapshots should be taken
--hour INTEGER Hour of the day when snapshots should be taken
--day-of-week TEXT Day of the week when snapshots should be taken
-h, --help Show this message and exit.

You can see the list of your snapshot schedules from the SLCLI with the following command.

 slcli file snapshot-schedule-list --help
Usage: slcli file snapshot-schedule-list [OPTIONS] VOLUME_ID

Lists snapshot schedules for a given volume

Options:
-h, --help Show this message and exit.





 Managing a Snapshot schedule with Terraform 

To set up a snapshot schedule, use the ibm_storage_file resource and specify information in the snapshot_schedule argument. The following example defines two different schedules. One schedule is for weekly snapshots that are take on Sundays at 1:20 PM. 20 snapshots are kept before the oldest one is deleted to make space for a new one. The second schedule is for hourly snapshots.

resource "ibm_storage_file" "fs_endurance" {
type = "Endurance"
datacenter = "dal09"
capacity = 20
iops = 0.25

 Optional fields
allowed_virtual_guest_ids = ["28961689"]
allowed_subnets = ["10.146.139.64/26"]
allowed_ip_addresses = ["10.146.139.84"]
snapshot_capacity = 10
hourly_billing = true

 Optional fields for snapshot
snapshot_schedule {
schedule_type = "WEEKLY"
retention_count = 20
minute = 20
hour = 13
day_of_week = "SUNDAY"
enable = true
}
snapshot_schedule {
schedule_type = "HOURLY"
* [Hyper Protect Crypto Services root key](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-create-root-keys). By default, the root key is created without an expiration date.



Key Protect: Need to set an expiration date to comply with internal security policies? [Create the root key by using the API](https://cloud.ibm.com/docs/key-protect?topic=key-protect-create-root-keyscreate-root-key-api) and include the expirationDate parameter. Important: Before your root key expires, repeat these steps to update your cluster to use a new root key. When a root key expires, the cluster secrets can't be decrypted and your cluster becomes unusable. Depending on the cluster version, the time lapse between the root key expiring and the cluster no longer being able to decrypt secrets might be about an hour, or when the master is refreshed.
3. Make sure that you have the correct permissions in IBM Cloud Identity and Access Management (IAM) to enable KMS in your cluster.



* Ensure that you have the [Administrator IBM Cloud IAM platform access role](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms) for the cluster.
* Ensure that the API key owner of the [API key](https://cloud.ibm.com/docs/containers?topic=containers-access-credsapi_key_about) that is set for the region and resource group that your cluster is in has the correct permissions for the KMS provider. For more information on granting access in IAM to the KMS provider, see the [Key Protect user access documentation](https://cloud.ibm.com/docs/key-protect?topic=key-protect-manage-access) or [Hyper Protect Crypto Services user access documentation](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-manage-accessplatform-mgmt-roles).
Action state 

Action state indicates the result of creating and processing an action that can be known to the Schematics system state. The table represents the Schematics Actions state and its description.



Action state

 State Description 

 Critical When the template is unable to download the repository, or the repository name is invalid, the template fails and changes the action state as critical. 
 Disabled Disallows user execution. 
 Locked After configuration is in Normal state. Action can be locked by an administrator to stop further change. 
 Normal Administrator publishes action to enable visibility to the users execution. 
 Pending When the user provides the template during create, update, or delete, your action goes into Pending state. 





 State diagram flow 

The following table represents the actions state workflow.



Action state workflow

 Action State diagram Description 

 Create ![Create action](https://cloud.ibm.com/docs-content/v1/content/ba89e173287b28d1453d2a327d8a1f74ae2f1662/schematics/images/createaction.png) When the user creates an action, initially the state of an action is in Draft state. If user provides the template during create or after create, then action goes to Pending state. If the template processing is success, action goes to Normal state. If the template manager sets disable to stop the usage, then action goes to Disable state. If there is an error in template processing, action goes to Critical state. 
 Delete ![Delete action](https://cloud.ibm.com/docs-content/v1/content/ba89e173287b28d1453d2a327d8a1f74ae2f1662/schematics/images/deleteaction.png) When the user selects to delete an existing action, initially action goes into Pending state. If the template deletion fails action goes to Critical state. 
 Update !
Deployment values 

The following deployment values can be used to configure the IBM Spectrum Symphony cluster instance on IBM Cloud.



Table 1. Deployment values

 Value Description Is it required? Default value 

 api_key This is the IBM Cloud API key for the IBM Cloud account where the IBM Spectrum Symphony cluster needs to be deployed. For more information on how to create an API key, see [Managing user API keys](https://cloud.ibm.com/docs/account?topic=account-userapikey). Yes None 
 cluster_id Unique ID of the cluster used by Symphony for configuration of resources. This must be up to 39 alphanumeric characters including the underscore (_), the hyphen (-), and the period (.). Other special characters and spaces are not allowed. Do not use the name of any host or user as the name of your cluster. You cannot change it after installation. No HPCCluster 
 cluster_prefix Prefix that is used to name the IBM Spectrum Symphony cluster and IBM Cloud resources that are provisioned to build the IBM Spectrum Symphony cluster instance. You cannot create more than one instance of the Symphony cluster with the same name. Make sure that the name is unique. No spectrum-symphony 
 dedicated_host_enabled Set to true to use dedicated hosts for compute hosts (default: false). Note that Symphony still dynamically provisions compute hosts at public virtual server instances and dedicated hosts are used only for static compute hosts that are provisioned at the time the cluster is created. The number of dedicated hosts and the profile names for dedicated hosts are calculated from worker_node_min_count and worker_node_instance_type. No false 
 dedicated_host_placement Specify 'pack' or 'spread'. The 'pack' option deploys virtual server instances on one dedicated host until full before moving on to the next dedicated host. The 'spread' option deploys virtual server instances in round-robin fashion across all the dedicated hosts. The second option should result in mostly even distribution of instances on the hosts, while the first option might result in one dedicated host being mostly empty. No spread
Active replicas and dependent duplicates can block reclamation of the Storage volume. Make sure that the volume is no longer mounted, host authorizations are revoked, replication is canceled, and no dependent duplicates exist before you attempt to cancel the original volume.





 Deleting a storage LUN from Terraform 

Use the terraform destroy command to conveniently destroy a remote object such as a single volume. The following example shows the syntax of the command.

terraform destroy --target ibm_storage_block.volumeID

For more information, see [terraform destroy](https://developer.hashicorp.com/terraform/cli/commands/destroy).

When the volume is canceled, the request is followed by a 24-hour reclaim wait period. You can still see the volume in the console during those 24 hours (immediate cancellation) or until the anniversary date. Billing for the volume stops immediately. When the reclaim-period expires, the data is destroyed and the volume is removed from the console, too. For more information, see the [FAQ](https://cloud.ibm.com/docs/BlockStorage?topic=BlockStorage-block-storage-faqs).

Active replicas and dependent duplicates can block reclamation of the Storage volume. Make sure that the volume is no longer mounted, host authorizations are revoked, replication is canceled, and no dependent duplicates exist before you attempt to cancel the original volume.
Retrieve a list of all actions in your IBM Cloud account.

Syntax

ibmcloud schematics action list [--limit LIMIT] [--offset OFFSET] [--profile PROFILE] [--output OUTPUT] [--json]

Command options



Schematics Actions list flags

 Flag Required / Optional Description 

 --limit or -l Optional The maximum number of actions that you want to list. The number must be a positive integer between 1 and 200. The default value is -1. 
 --offset or -m Optional The position of the action in the list of actions from where you want to start listing your actions. For example, if you have three actions in your account, the command returns these actions as a list with three elements. To retrieve all actions, you must enter position number 0. To retrieve actions number 2 and 3 and leave out action number 1 in this list, you must enter position number 1. Position number 1 represents the second position in the list of actions. Negative numbers are not supported and are ignored. 
 --profile or -p Optional The depth of information that is returned. Supported values are ids, and summary. The default value is summary. 
 --output or -o Optional Returns the command-line output in JSON format. Currently only JSON file format is supported. 
 --json or -j Deprecated Prints the output in the JSON format. 



Example

ibmcloud schematics action list --profile ids





 ibmcloud schematics action delete 

Delete a Schematics action.

Syntax

ibmcloud schematics action delete --id ACTION_ID [--force]

Command options



Schematics Actions delete flags

 Flag Required / Optional Description 

 --id or -i Required The ID of an action that you want to delete. 
 --force or -f Optional Force the deletion without user confirmation. 
 --no-prompt Optional Set this flag to run the command without user prompts. 



Example

ibmcloud schematics action delete --id us-south.workspace.101010101





 ibmcloud schematics action upload
[Menu icon](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/icons/icon_hamburger.svg) > VPC Infrastructure > Compute > SSH keys. Any existing SSH keys are displayed.
2. On the SSH keys for VPC tab, click the Actions icon ![More Actions icon](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/icons/action-menu-icon.svg) for an SSH key and select from the available options.



Table 1. SSH key actions

 Action Description 

 Rename After you update an existing SSH key, the key is renamed immediately. 
 Delete After you remove an SSH key, it can no longer be used when you provision an instance or when you perform an OS reload on an existing instance. However, the key is still available on any instances that you previously provisioned with it, and you can use it to log in. 



You are shown a list of the available regions for your specific resource group.







 Managing SSH keys by using the CLI 

You can also manage your SSH keys by using the CLI.

Make sure that the IBM Cloud CLI vpc-infrastructure plug-in is installed. For more information, see [IBM Cloud CLI for VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-set-up-environment).



Table 1. SSH key actions

 Action Command What happens next 

 Create SSH key. [ibmcloud is key-create](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-reference&interface=clikey-create) After you create an SSH key, it is added to the list of keys. 
 View key details.
To start a resync through the API, send a POST to the [/deployments/{id}/remotes/resync](https://cloud.ibm.com/apidocs/cloud-databases-apiresync-read-only-replica) endpoint.

curl -X POST https://api.{region}.databases.cloud.ibm.com/v4/ibm/deployments/{id}/remotes/resync -H 'Authorization: Bearer <>'





 Promoting a Read-only Replica in the UI 

A read-only replica is able to be promoted to an independent cluster that can accept write operations as well as read operations. If something happens to the leader deployment, the read-only replica can be promoted to a stand-alone cluster and start accepting writes from your application.

To promote a read-only replica from the UI, click Promote Read-Only Replica.

Upon promotion, the read-only replica terminates its connection to the leader and becomes a stand-alone Databases for EnterpriseDB deployment. The deployment can start accepting and running read and write operations, backups are enabled, and it is issued its own admin user. A new data member is added so the deployment becomes a cluster with two data members. This increases the cost as it is billed at the same per member consumption rate, but the deployment has two members instead of one.

When you promote a read-only replica, you can skip the initial backup that would normally be taken upon promotion. Skipping the initial backup means that your replica becomes available more quickly, but no immediate backup is available. You can start an on-demand backup once the promotion process is complete.

Once a read-only replica is promoted to an independent deployment, it is not possible to revert it back to a read-only replica or have it rejoin a leader.





 Promoting a Read-only Replica in the CLI 

Upon promotion, the read-only replica terminates its connection to the leader and becomes a stand-alone Databases for EnterpriseDB deployment. The deployment can start accepting and running read and write operations, backups are enabled, and it is issued its own admin user. A new data member is added so the deployment becomes a cluster with two data members.
For more details about how certificate authorities are used to establish identity, see [Hyperledger Fabric documentation](https://hyperledger-fabric.readthedocs.io/en/release-2.1/identity/identity.html).

Each organization in the network has their own CA. Your organization CA signs requests for all of the entities and components that you own, such as your admin, peers, or applications. If you want to add a node or new application to your network, you need to register the new user with your Certificate Authority (registration). Then, via the enrollment process, the CA generates a public and private key pair. The "enrollment certificate", also known as the signed certificate or public key, is shared with the network.





 Overview 

The following diagram shows all of the certificates that need to be managed and where they reside on your network.

Zoom

![Certificate overview diagram](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/blockchain/images/cert-expiration-all.png)

Figure 1. Certificate overview diagram

The left column includes the certificates for the blockchain CA, peer, and ordering nodes. There are two certificates that are included on the CA node, the CA root certificate and the CA TLS cert. The root certificate is included here for completeness, but because it expires in 15 years, update instructions are not provided. The peer and ordering nodes are similar in that they both contain an enrollment certificate (the public key or signed certificate), their TLS certificate that enables them to transact with other nodes in their organization, and their MSP admin certificate, which represents the admin identity that is allowed to administer the node.

The IBM Blockchain Platform can automatically renew the enrollment certs for the peer and ordering nodes and the TLS certificate for the peer. But the MSP admin identities have to be manually renewed. If the MSP is enabled for Node Organizational Units (Node OUs), no further action is required.
[No changes](https://cloud.ibm.com/docs-content/v1/content/ca9232b3702768f24bb897f48f10778fcda28718/watson-assistant/images/no-new-changes-publish.png)

No changes







 What is being published? 

When you publish, a snapshot is taken of the current state of actions. All updates to actions content are published in a version, including the following updates:



* Creating an action
* Editing an action
* Editing actions settings
* Deleting actions
* Creating variables
* Editing variables
* Deleting variables



If you are using [dialog with actions](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-migrate-overview), these updates are published:



* Activating dialog
* Creating a dialog
* Editing a dialog
* Editing dialog settings
* Deleting a dialog



The following updates are not published in a version and must be configured manually for each environment:



* Channel configurations
* Environment settings







 Publishing or switching versions in the live environment 

There are two ways to publish a version to the live environment:



* When you publish a version from the draft environment
* Use the Live environment tab and click Publish version.



After a version is published to the live environment, there are two ways you can switch to a different version:



* When you publish a version from the draft environment, you have the option of assigning it to the live environment, replacing the one that's already there
* Use the Live environment tab and click Switch version.







 Reverting to a previous version 

Use the revert function if you need to update a version of content that is already published to a version. For example, if you publish V1 of your content and then notice an error, you can revert your actions to V1 and use the draft environment to correct the error.

If you revert to a previous version, your published content isn't affected, but the content on the Actions page is overwritten with the version that you revert to.
: Let's Encrypt refused to generate a new certificate for this domain. This usually happens when the cluster is deleted and recreated with the same name, or the ibmcloud oc nlb-dns secret regenerate command was invoked multiple times. The rate limit will expire after 7 days (there is no way to manually remove it). Certificate generation will be automatically attempted again after 7 days.
3. Wait 10-15 minutes, then check if the warning is resolved.
4. If the issue persists, contact support. Open a [support case](https://cloud.ibm.com/docs/get-support?topic=get-support-using-avatar). In the case details, be sure to include any relevant log files, error messages, or command outputs.