vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* Events are archived within 24-48 hours after you save the configuration.
* Logs are archived hourly.
* The archive directory format looks like this:

year=<YYYY>/month=<MM>/day=<DD>/<accountID>.<YYYY>-<MM>-<DD>.<HHHH>.json.gz

Where

YYYY represents the year; MM represents the month; and DD represents the day.

<accountID> represents the auditing account ID, that is, the ID that showd in the [web UI URL](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-get_web_url).

HHHH represents hours in 24 format.
* The timestamp that is used to determine whether the event is included in an archive is the UTC timestamp.

Depending on your location, there might be events that you see in local time in your views on a specific day. However, you cannot find them in the archive file. You are most likely viewing events in local time and the archive process uses the UTC timestamp.
* After you configure archiving, the first archive file is created when the archiving process runs and there is data.
* The first time the archive process runs the number of days archived is dependent on the plan:



* The maximum number of days that data is archived includes events for the past 30 days when the instance has a 30 day search plan.
* The maximum number of days that data is archived includes events for the past 14 days when the instance has a 14 day search plan.
* The maximum number of days that data is archived includes events for the past 7 days when the instance has a 7 day search plan.





For example, you have a service plan of 30 days. You configured the instance 10 days ago. You enable archiving on the 10th day. The archiving process generates multiple files. Each file includes events for the period of time indicated as part of its name. If there is no data, the archive file for that period is empty.

Each IBM Cloud Activity Tracker instance has its own archiving configuration.
When the reclaim period expires, the data is destroyed and the volume is removed from the console, too.





 How can we tell which Block Storage for Classic volumes are encrypted? 

When you look at your list of Block Storage for Classic in the [IBM Cloud® console](https://cloud.ibm.com/login), you can see a lock icon next to the volume name for the LUNs that are encrypted.





 How do we know when we're provisioning Block Storage for Classic in an upgraded data center? 

When you order Block Storage for Classic, all upgraded data centers are denoted with an asterisk () in the order form, and an indication that you're about to provision storage with encryption. When the storage is provisioned, you can see an icon in the storage list that shows that storage as encrypted. You can find a full list of upgraded data centers and available features [here](https://cloud.ibm.com/docs/BlockStorage?topic=BlockStorage-selectDC).





 If we own nonencrypted Block Storage for Classic in a data center that was recently upgraded, can we encrypt that Block Storage for Classic? 

Block Storage for Classic that is provisioned before the data center upgrade can't be encrypted. New Block Storage for Classic that is provisioned in upgraded data centers is automatically encrypted. Data on nonencrypted storage in an upgraded data center can be encrypted by creating a LUN, then copying the data to the new encrypted LUN with host-based migration. For more information, see [Upgrading existing Block Storage for Classic to enhanced Block Storage for Classic](https://cloud.ibm.com/docs/BlockStorage?topic=BlockStorage-migratestoragemigratestorage).





 Does Block Storage for Classic support SCSI-3 Persistent Reserve to implement I/O fencing for Db2 pureScale? 

Yes, Block Storage for Classic supports both SCSI-2 and SCSI-3 persistent reservations.





 What happens to the data when Block Storage for Classic LUNs are deleted? 

IBM Cloud® Block Storage for Classic presents Block volumes to customers on physical storage that is wiped before any reuse.
This includes changing the existing steps and adding or deleting steps. Note that if you change the No action matches action, you might accidentally break your assistant's ability to recover from errors in the conversation. If this happens, you can recreate the default steps based on the information in this section.



 Adding examples of unsupported input 

By default, the No action matches action is triggered only when the user's input does not match any defined action.

If there are certain user requests that you can anticipate, but that your assistant does not support, you can add these requests as example phrases in the Customer starts with section of the No action matches action. Adding example phrases helps to ensure that these requests are sent directly to the No action matches action rather than triggering a different action by mistake. You can also upload or download examples phrases in a comma-separated value (CSV) file, just like you can when building your own actions. For more information on uploading or downloading example phrases, see [Adding more examples](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-understand-questionsunderstand-questions-adding-more-examples).







 When your customer gives invalid answers 

When a step in an action asks your customer to answer questions or provide additional information, the assistant expects a particular response type, such as a number, date, or text string. (For more information about customer response types, see [Collecting information from your customer](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-collect-info).) The assistant checks the customer's response to make sure it fits the expected response type; this process is called validation.

For most customer response types, the assistant is able to understand valid responses provided in a variety of formats. For example, for a time value, 2:15 PM and a quarter past two in the afternoon are both acceptable. But if the user provides a value that the assistant cannot interpret as matching the expected response type (for example, a response of purple when asked for a number), a validation error results.

When there is a validation error, the assistant asks the customer to try again.
When the cluster autoscaler detects pending pods, the autoscaler scales up your worker nodes evenly across zones to meet the workload resource requests.
* Underutilized worker nodes to scale down: By default, worker nodes that run with less than 50% of the total compute resources that are requested for 10 minutes or more and that can reschedule their workloads onto other worker nodes are considered underutilized. If the cluster autoscaler detects underutilized worker nodes, it scales down your worker nodes one at a time so that you have only the compute resources that you need. If you want, you can [customize](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-enable) the default scale-down utilization threshold of 50% for 10 minutes.



Scanning and scaling up and down happens at regular intervals over time, and depending on the number of worker nodes might take a longer period of time to complete, such as 30 minutes.

The cluster autoscaler adjusts the number of worker nodes by considering the [resource requests](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/) that you define for your deployments, not actual worker node usage. If your pods and deployments don't request appropriate amounts of resources, you must adjust their configuration files. The cluster autoscaler can't adjust them for you. Also, keep in mind that worker nodes use some compute resources for basic cluster functionality, default and custom [add-ons](https://cloud.ibm.com/docs/containers?topic=containers-updateaddons), and [resource reserves](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodesresource_limit_node).

What does scaling up and down look like?
: In general, the cluster autoscaler calculates the number of worker nodes that your cluster needs to run its workload. Scaling the cluster up or down depends on many factors, including the following.



* The minimum and maximum worker node size per zone that you set.
The following tables describe the types of certificates that you need to manage, how to view their expiration date, and how to maintain them.



 CA TLS certificate 



Table 1. How to manage the CA certificates

 Certificate Description How generated Default expiration How to view expiration How to renew Impact if expires What to do if expired 

 CA TLS certificate Used to trust the CA server. Contains the public key that must be shared with all members in the organization that want to transact with any node in the organization. When any client or node submits a transaction to another node, it must include this certificate as part of the transaction to prevent “man in the middle” attacks. Generated when the CA is first started because TLS is enabled. 2.5.x: 10 years <br> <br>2.1.x: 1 year If it expires within five years, the expiration date is visible from the console. Open CA node and view TLS Cert Expiration field See [Renew the CA TLS certificate](https://cloud.ibm.com/docs/blockchain?topic=blockchain-cert-mgmtcert-mgmt-ca-tls). Transactions continue. <br> <br>- Cannot register or enroll new identities, but transaction traffic does not stop. <br> <br>- Automatic certificate renewal fails. <br> <br>- Cannot renew other certificates without fixing CA TLS certificate first. See [Renew the CA TLS certificate](https://cloud.ibm.com/docs/blockchain?topic=blockchain-cert-mgmtcert-mgmt-ca-tls). 







 Peer certificates 



Table 2. How to manage the peer certificates

 Certificate Description How generated Default expiration How to view expiration How to renew Impact if expires What to do if expired 

 Peer enrollment certificate (signcert) The public key that is used to verify that the signatures that nodes attach to communications were generated by the node's private key. Generated when the peer is deployed based on the peer enroll ID and secret that is provided. 1 year Open console peer node and view Enrollment Cert Expiration field.
The logs can be checked at cd /var/adm/ras and cat mmsysmonitor.log.





 Why does my cluster deployment fail in Schematics with a signal KILL error? 

 What’s happening 

While Schematics sets up the cluster, the deployment fails with an error similar to: Error: error executing "/tmp/terraform_516879781.sh": Process exited with status 137 from signal KILL

Cluster provisioning is a two-phase process. In the first phase, Schematics deploys some initial resources and the bastion host. In the second phase, Schematics uses SSH for remote access from the bastion host to the bootstrap node and then starts the subsequent resource provisioning. During the second phase, if any resource provisioning takes too long, Schematics stops the SSH process, which results in the signal KILL error. This can happen if bare metal provisioning takes longer than 40 minutes.

 Why it’s happening 

Since Schematics is a free service, there is a time limit of one hour on remote execution. If the one hour time limit elapses, Schematics automatically stops the deployment and returns a signal KILL error.

 How to fix it 

The only way to fix this issue is by cleaning up all of the resources from the failed deployment and then trying to do a new deployment.





 Why does my cluster deployment fail with a "unique name" error? 

 What’s happening 

During cluster provisioning, the deployment fails with the following error: The provided name is not unique name: <bare_metal_server_name>.

In the cloud environment, all of the resources should be uniquely named. During cluster provisioning, all resource names are stored in a backend database. If a cluster provisioning attempt fails and you try to clean up resources from this failed attempt, it can take a while for the resource names to be cleaned up from the backend database. If during a subsequent reprovisioning attempt the same cluster prefix is used, it's possible that the new resources' names collide with the stale entries from the previous attempt.

 How to fix it 

After a failed deployment, clean up all resources.
@sys-percentage.literal string If input contains 50 percent returns 50 percent. 
 @sys-percentage.location array If input contains from 2 to 3 percent, returns [0,19]. 
 @sys-percentage.numeric_value number If input contains 50 percent returns 50. 
 @sys-percentage.range_link string If input contains from 2 to 3 percent, returns number_range_0_19. 







 @sys-percentage usage tips 



* If you use the @sys-percentage entity as a node condition and the user specifies 0% as the value, the value is recognized as a percentage properly, but the condition is evaluated to the number zero not the percentage 0%. As a result, the null in the condition is evaluated to false and the node is not processed. To check for percentages in a way that handles zero percentages properly, use the expression @sys-percentage OR @sys-percentage == 0 in the node condition instead.
* If you input a value like 1-2%, the values 1% and 2% are returned as system entities.









 Using system entities in conditions 

In a node that conditions on the Customer_Care_Store_Hours intent, you can add conditional responses that use new system entity properties to provide slightly different answers about store hours depending on what the user asks.

You probably do not want to use all of these conditional responses in a real dialog; they are described here merely to illustrate what's possible.



System entities in conditional responses

 Conditional response condition syntax Description Example response text 

 @sys-date.festival == 'thanksgiving' Checks whether the customer is asking about hours on Thanksgiving day in particular. We give out free meals to those in need on Thanksgiving Day. 
 @sys-date.festival Checks whether the customer is asking about hours on another specific holiday. We are closed on Christmas Day, July 4th, and President's Day. On other holidays, we are open from 10AM to 5PM. 
 @sys-time.part_of_day == 'night' Checks whether the user includes any terms that mention night as the time of day in the input. We are not open late; we close at 9PM most days.
The index rate is calculated as the average value of all index rates that are calculated over 24 hours.



To calculate the hourly average index rate, also known as the standard hourly index rate, the following formula is applied:



1. The total number of indexed lines for the past hour, that is, the number of log lines over 1 hour rolling period, is collected.
2. The total number of indexed lines per hour is then divided by 60 to get the average of log lines per minute.
3. The average log lines per minute is then divided by 60 to get the average of log lines per second.
4. The index rate is calculated as the average value of all index rates that are calculated over the last hour by using 5 minutes increments.



The daily min index rate is the lowest index rate calculated over a 24 hour period.

The daily max index rate is the highest index rate calculated over a 24 hour period.

The max lines threshold indicates the maximum number of lines per second that you configure for your instance. This number represents the maximum number of lines that you expect to ingest per second for that instance.

If no log lines are ingested for over a 60-minute period, you get a Check Later message instead of the index rate value. When the ingestion of log lines is resumed, you get the index rate value. Measurements are taken every five minutes, therefore, the first measurement of ingested log lines for that five minutes will be averaged out for the full hour. Wait at least 1 hour before using the index rate value for analysis.

Only one alert for each alert channel will be sent until the hour or day has elapsed. This alert will show all thresholds that have been exceeded during the period. If index rate alerts are configured on each separate threshold, an alert will be sent indicating the first threshold crossed (either Max lines/s, Max z-score, or both)





 Types of index rate alerts 

There are two types of index rate alerts:



* Max lines/s alerts: Use this alert to monitor and control the number of log lines per second that are indexed and stored for search.
The time ranges for different parts of the day can differ by locale. For US English, morning is 6:00:00 to 12:00:00, afternoon is 12:00:00 to 18:00:00, evening is 18:00:00 to 22:00:00, and night is 22:00:00 to 23:59:59. Night ends just before midnight because otherwise it would overlap with a new day, which is measured by @sys-date.
* .range_link: If present, indicates that the user's input contains a time range. The start and end index values of the string that includes the time range are saved as part of the link name. Additional information is provided, including the role that each @sys-time plays in the range relationship. For example, the start time has a role type of time_from and the end time has a role type of time_to. To check a role value, you can use the syntax @sys-time.role?.type == 'time_from'. If the user input implies a range, but only one time is specified, then the range_link property is not returned, but one role type is returned. A range_modifier that identifies the word in the input that triggers the identification of a range is also returned.
* .relative_{timeframe}: Recognizes relative mentions of time and returns a number that shows the number of units between now and the specified time. The {timeframe} units can be hour, minute, or second.
* .second: Helper method that returns the second value that is specified in the time.
* .specific_{timeframe}: Recognizes and captures mentions of specific time units in the user input. The {timeframe} units can be hour, minute, or second.



The following table illustrates the information that each attribute captures from the user input.



@sys-time attributes

 Attribute Type Example 

 @sys-time string For the input 6:30 PM, returns 18:30:00. 
 @sys-time.alternatives array If a user says The meeting is at 5, the system calculates the time as 5:00:00 or 5 AM and saves that as the @sys-time.
The time ranges for different parts of the day can differ by locale. For US English, morning is 6:00:00 to 12:00:00, afternoon is 12:00:00 to 18:00:00, evening is 18:00:00 to 22:00:00, and night is 22:00:00 to 23:59:59. Night ends just before midnight because otherwise it would overlap with a new day, which is measured by @sys-date.
* .range_link: If present, indicates that the user's input contains a time range. The start and end index values of the string that includes the time range are saved as part of the link name. Additional information is provided, including the role that each @sys-time plays in the range relationship. For example, the start time has a role type of time_from and the end time has a role type of time_to. To check a role value, you can use the syntax @sys-time.role?.type == 'time_from'. If the user input implies a range, but only one time is specified, then the range_link object is not returned, but one role type is returned. A range_modifier that identifies the word in the input that triggers the identification of a range is also returned.
* .relative_{timeframe}: Recognizes relative mentions of time and returns a number that shows the number of units between now and the specified time. The {timeframe} units can be hour, minute, or second.
* .second: Helper method that returns the second value that is specified in the time.
* .specific_{timeframe}: Recognizes and captures mentions of specific time units in the user input. The {timeframe} units can be hour, minute, or second.



The following table illustrates the information that each attribute captures from the user input.



@sys-time attributes

 Attribute Type Example 

 @sys-time string For the input 6:30 PM, returns 18:30:00. 
 @sys-time.alternatives array If a user says The meeting is at 5, the system calculates the time as 5:00:00 or 5 AM and saves that as the @sys-time.
The index rate is calculated as the average value of all index rates that are calculated over 24 hours.



To calculate the hourly average index rate, also known as the standard hourly index rate, the following formula is applied:



1. The total number of indexed lines for the past hour, that is, the number of log lines over 1 hour rolling period, is collected.
2. The total number of indexed lines per hour is then divided by 60 to get the average of log lines per minute.
3. The average log lines per minute is then divided by 60 to get the average of log lines per second.
4. The index rate is calculated as the average value of all index rates that are calculated over the last hour by using 5 minutes increments.



The daily min index rate is the lowest index rate calculated over a 24 hour period.

The daily max index rate is the highest index rate calculated over a 24 hour period.

The max lines threshold indicates the maximum number of lines per second that you configure for your instance. This number represents the maximum number of lines that you expect to ingest per second for that instance.

If no log lines are ingested for over a 60-minute period, you get a Check Later message instead of the index rate value. When the ingestion of log lines is resumed, you get the index rate value. Measurements are taken every five minutes, therefore, the first measurement of ingested log lines for that five minutes will be averaged out for the full hour. Wait at least 1 hour before using the index rate value for analysis.

Only one alert for each alert channel will be sent until the hour or day has elapsed. This alert will show all thresholds that have been exceeded during the period. If index rate alerts are configured on each separate threshold, an alert will be sent indicating the first threshold crossed (either Max lines/s, Max z-score, or both).





 Types of index rate alerts 

There are two types of index rate alerts:



* Max lines/s alerts: Use this alert to monitor and control the number of log lines per second that are indexed and stored for search.