vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Create the Periodic Slack Reminder trigger. Triggers invoke actions when they receive events from event sources. Specify the trigger's time interval by using a Pattern or Cron expression.
<-- <ul> -->

* Pattern - Select UTC times for weekdays, hours, and minutes.
* Cron - Specify a cron sequence based on the UNIX crontab syntax]]! ! ! ! ! . Use five or fewer separated by spaces in the format X X X X X.

<-- </ul> -->

6. Click Deploy.<-- </ol> -->After the template deploys, you can make further edits to the code to customize it as needed, or go back and check out the catalog of available templates.<-- </section "id="section-slack-reminder-template-ui" "> --><-- <section "id="section-slack-reminder-template-cli" "> --> Deploying the Periodic Slack Reminder template from the CLI Use the CLI to deploy the Periodic Slack Reminder template.Before you begin<-- <ul> --> * Install the Cloud Functions]] CLI. * Specify a namespace to contain your Cloud Functions entities. For more information about namespaces, see Managing namespaces]] ! ! !.<-- </ul> --><-- <ol> -->1. Clone the template repo.
git clone https://github.com/ibm-functions/template-reminder-slack.git
2. Navigate to the directory for the action runtime that you want to use. For example, nodejs.
cd template-reminder-slack/runtimes/nodejs
3. Deploy the template with the following environment variables.
SLACK_WEBHOOK_URL=<url> ALARM_CRON=<cron> PACKAGE_NAME=<name> RULE_NAME=<name> TRIGGER_NAME=<name> ibmcloud fn deploy -m manifest.yaml

<-- <table> -->

Table 4.
* [Schematics Terraform depreciation lifecycle](https://cloud.ibm.com/docs/schematics?topic=schematics-deprecate-tf-versiondeprecate-phase)



* [Terraform maintenance and fixes](https://cloud.ibm.com/docs/schematics?topic=schematics-deprecate-tf-versiondeprecate-maintenance)
* [Restrict workspace creation](https://cloud.ibm.com/docs/schematics?topic=schematics-deprecate-tf-versiondeprecate-wks-create)
* [Restrict workspace execution](https://cloud.ibm.com/docs/schematics?topic=schematics-deprecate-tf-versiondeprecate-wks-execute)



* [Depreciation Schedule](https://cloud.ibm.com/docs/schematics?topic=schematics-deprecate-tf-versiondeprecate-timeline)
* [User actions](https://cloud.ibm.com/docs/schematics?topic=schematics-deprecate-tf-versionuser-action)



[Updating to a new Terraform version](https://cloud.ibm.com/docs/schematics?topic=schematics-migrating-terraform-versionmigrating-terraform-version)



* [Upgrading the Terraform template version 1.x and above](https://cloud.ibm.com/docs/schematics?topic=schematics-migrating-terraform-versionterraform-version-upgrade1x)



* [Updating the Workspace Terraform 1.x version](https://cloud.ibm.com/docs/schematics?topic=schematics-migrating-terraform-versionterraform-version-upgrade1x-process)
But a user might receive duplicate text messages if a change is not treated idempotently when replayed changes occur.

Usually these "rewinds" of the changes feed are short, replaying only a handful of changes. But in some cases, a request might see a response with thousands of changes replayed - potentially all of the changes from the beginning of time. The potential for rewinds makes the changes feed unsuitable for an application that expects queue-like behavior.

To reiterate, IBM Cloudant's changes feed promises to deliver a document at least one time in a changes feed, and gives no guarantees about repeated values across multiple requests.





 Does the changes feed operate in "real time"? 

The changes feed doesn't guarantee how quickly an incoming change appears to a client that consumes the changes feed. Applications must not be developed with the assumption that data inserts, updates, and deletes are immediately propagated to a changes reader.





 Why don't all individual document changes appear in the changes feed? 

If a document is updated several times in between changes feed calls, then the changes feed might reflect only the most recent of these changes. The client does not receive every change to every document.

The IBM Cloudant changes feed isn't a transaction log that contains every event that happened in time order.





 Can I use a filtered changes feed for operational queries? 

Filtering the changes feed, and by extension, running filtered replication has its uses:



* Copying data from source to target but ignoring deleted documents.
* Copying data but without index definitions (design documents).



This [blog post](https://blog.cloudant.com/2019/12/13/Filtered-Replication.html) describes how supplying a selector during replication makes work of these use cases run smoothly.

The changes feed with an accompanying selector parameter is not the way to extract slices of data from the database on a routine basis. It must not be used as a means of running operational queries against a database. Filtered changes are slow (the filter is applied to every changed document in turn, without the help of an index). This process is much slower than creating a secondary index (such as a MapReduce view) and querying that view.
instance schedule_reclaim An event is generated when a service instance scheduled for reclaim after deletion. 
 instance update An event is generated when a service instance get updated. 
 instance update_failure An event is generated when a service instance updation failed. 
 instance update_inprogress An event is generated when a service instance updation is in progress. 
 instance update_plan An event is generated when a service instance plan get updated. 
 instance update_plan_failure An event is generated when a service instance plan updation failed. 
 instance update_plan_inprogress An event is generated when a service instance plan updation is in progress. 
 instance update_state An event is generated when a service instance state get updated. 
 instance update_state_failure An event is generated when a service instance state updation failed. 



2. Service key type resources



Table 2. Supported key credentials type and sub-types

 Event type Sub-type Description 

 key create An event is generated when a service instance credentials are created successfully. 
 key create_failure An event is generated when a service instance credentials creation failed. 
 key delete An event is generated when a service instance credentials deleted successfully. 
 key delete_failure An event is generated when a service instance credentials deletion failed. 



3. Resource Group resources



Table 3. Supported resource group type and sub-types

 Event type Sub-type Description 

 Resource_group create An event is generated when a resource group get created. 
 Resource_group delete An event is generated when a resource group get deleted. 
 Resource_group update An event is generated when a resource group get updated. 









 Enabling resource lifecycle events 

IBM Cloud Resource lifecycle events is a pre-defined source which publishes resource lifecycle events from IBM Cloud. IBM Cloud Resource lifecycle events is Disabled by default. You can go to the Sources page and enable it by using the toggle switch.

After enabling the source, you can publish the lifecycle events to the [Topic](https://cloud.ibm.com/docs/event-notifications?topic=event-notifications-en-overviewen-topics) of your choice.
---------------------------------------------------------------------------------------------------------------------------------------------------
Show more

 update the policy to three months

ibmcloud kp key policy-update rotation 4d5540bd-3235-4a46-a8af-974f7ed6558a -m 3 -e --output json

{
"createdBy": "user id ...<redacted>...",
"creationDate": "2022-12-02T00:50:11Z",
"crn": "crn:v1:bluemix:public:kms:us-south:a/e3e8fd14a61a49cda102faad15b06c09:5ecfe306-d4af-48c0-ab07-b5c5bc751534:policy:0ec7ad62-982d-45bb-895f-986d95015f5b",
"lastUpdateDate": "2022-12-02T00:51:38Z",
"updatedBy": "user id ...<redacted>...",
"rotation": {
"enabled": true,
"interval_month": 3
}
}
How does priority scheduling and preemption work?

In general, pending pods that have a higher priority are scheduled before lower prioritized pods. If you don't have enough resources remaining in your worker nodes, the Red Hat OpenShift controller can preempt (remove) pods to free up enough resources for the higher prioritized pods to be scheduled. Preemption is also affected by graceful termination periods, pod disruption budgets, and worker node affinity.

If you don't specify a priority for your pod deployment, the default is set to the priority class that is set as the globalDefault . If you don't have a globalDefault priority class, the default priority for all pods is zero (0). By default, Red Hat OpenShift on IBM Cloud does not set a globalDefault, so the pod default priority is zero.

To understand how pod priority and Red Hat OpenShift controller work together, consider the scenarios in the following figure. You must place prioritized pods on worker nodes with available resources. Otherwise, high priority pods in your cluster can remain in pending at the same time that existing pods are removed, such as in Scenario 3.

Zoom

![Pod priority scenarios.](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/openshift/images/pod-priority.png)

Figure 1. Pod priority scenarios



1. Three pods with high, medium, and low priority are pending scheduling. The Red Hat OpenShift controller finds an available worker node with room for all three pods, and schedules them in order of priority, with the highest priority pod scheduled first.
2. Three pods with high, medium, and low priority are pending scheduling. The Red Hat OpenShift controller finds an available worker node, but the worker node has only enough resources to support the high and medium priority pods. The low-priority pod is not scheduled and it remains in pending.
3. Two pods with high and medium priority are pending scheduling. A third pod with low priority exists on an available worker node.
<Status>Enabled</Status>
<Transition>
<Days>20</Days>
<StorageClass>ACCELERATED</StorageClass>
</Transition>
</Rule>
</LifecycleConfiguration>

Sample Response

HTTP/1.1 200 OK
Date: Wed, 7 Feb 2018 17:51:00 GMT
Connection: close



* Java
* Python
* Node



public SetBucketLifecycleConfigurationRequest(String bucketName,
BucketLifecycleConfiguration lifecycleConfiguration)

response = client.put_bucket_lifecycle_configuration(
Bucket='string',
LifecycleConfiguration={
'Rules': [
{
'ID': 'string',
'Status': 'Enabled',
'Filter': '',
'Prefix': '',
'Transitions':
{
'Date': datetime(2015, 1, 1),
'Days': 123,
'StorageClass': 'GLACIER'
},
]
},
]
}
)

var params = {
Bucket: 'STRING_VALUE', /* required /
LifecycleConfiguration: {
Rules: [ /* required /
{
Status: 'Enabled', /* required /
ID: 'STRING_VALUE',
Filter: '', /* required /
Prefix: '',
Transitions:
{
Date: DATE, /* required if Days not specified /
Days: 0, /* required if Date not specified /
StorageClass: 'STRING_VALUE' /* required /
},
]
},
]
}
};

s3.putBucketLifecycleConfiguration(params, function(err, data) {
if (err) console.log(err, err.stack); // an error occurred
else console.log(data); // successful response
});

Method Summary
Managing API and Product versions in API Connect V5 

After publishing an API and the product that contains it, API providers typically need to update those products and APIs. Updating an API product can happen in different ways; for example:



*  Completely replace the old API product with a new version, automatically updating all subscriptions.
*  Supersede the old API product with the new version, manually updating individual subscriptions.



To replace an API, take the API product out of service and then remove it by completing the following tasks:



*  Deprecate the API product: Prevent new subscriptions to the API but do not prohibit usage.
*  Retire the API product: Prevents any use of the API but do not remove it.
*  Archive the API product: Remove the API from use but do not delete it completely. The API can be can be reinstated if needed.
*  Delete the API product: Permanently delete API product.



In this series of tutorials, you will move API products through all of these states. Complete the tutorials in the following sequence:



1.  [Replace an API product](https://cloud.ibm.com/docs/apiconnect/tutorials?topic=apiconnect-tut_manage_replace).
2.  [Supersede an API product](https://cloud.ibm.com/docs/apiconnect/tutorials?topic=apiconnect-tut_manage_supercede).
3.  [Archive and delete an API product](https://cloud.ibm.com/docs/apiconnect/tutorials?topic=apiconnect-tut_manage_remove).
Data deleted (if it existed) at: ibmcloud/arbitrary/secrets/d26702aa-77ae-400e-4f25-9790a9cabf9c









 Dynamic secrets 

Dynamic secrets are single-use credentials that are generated only when they are read or accessed.

To create a dynamic secret by using the Vault CLI, use the role command to scope the secret with the wanted level of permissions in your IBM Cloud account. Then, use the creds command to generate credentials for the role.



 Create a role 

Use the following commands to register a role for a [secrets engine that supports dynamic secrets](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-what-is-secretsecret-types). After you create a role, you can [generate credentials](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-vault-clivault-cli-create-iam-creds-for-role) for it. The configuration that you define for role, such as its name, lease duration, and access permissions, is inherited by the generated credentials.

Create a role in the default secret group.

vault write [-format=FORMAT] ibmcloud/SECRET_TYPE/roles/ROLE_NAME access_groups=ACCESS_GROUP_ID,ACCESS_GROUP_ID ttl=LEASE_DURATION [description="DESCRIPTION"] [labels=LABEL,LABEL]

Create a role in a specified secret group.

vault write [-format=FORMAT] ibmcloud/SECRET_TYPE/roles/groups/SECRET_GROUP_ID/ROLE_NAME access_groups=ACCESS_GROUP_ID,ACCESS_GROUP_ID ttl=LEASE_DURATION [description="DESCRIPTION"] [labels=LABEL,LABEL]



 Prerequisites 

You need the [Writer service role](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-iam) to create secrets.





 Command options 

SECRET_TYPE
: The type of secret that you want to create. Currently, iam_credentials is supported.

SECRET_GROUP_ID
Creating a lock on the current version of your secret with both the Delete matching locks and Delete previous version data options results in removing lock-z from the previous version. Additionally, because the previous version doesn't have any other locks that are attached to it, the secret data that is associated with the previous version is also deleted. 





 Creating a lock on the current secret version 

You can lock the current version of a secret by using the Secrets Manager CLI. A successful request attaches a new lock to the current version of your selected secret, or replaces a lock of the same name if it already exists.

To create a lock on the current version of a secret by using the Secrets Manager CLI plug-in, run the ibmcloud secrets-manager secret-lock command. You can specify the type of secret, the secret ID, and the mode.

ibmcloud secrets-manager secret-locks-bulk-create --id=exampleString --locks='[{"name": "lock-example-1", "description": "lock for consumer 1", "attributes": {"anyKey": "anyValue"}}]' --mode=remove_previous







 Creating locks with the API 

You can create up to 1000 locks on a secret by using the Secrets Manager API. Each lock can be used to represent a single application or consumer that uses your secret. A successful request attaches a new lock to your secret, or replaces a lock of the same name if it already exists.

A secret is considered locked after you attach one or more locks to it. A lock can be applied only on a secret version that contains active payload, or secret data.

To help you to create a new lock and remove older locks in a single operation, you can also specify an optional mode at lock creation.



Table 1. Optional lock modes and their descriptions

 Mode Query parameter Description 

 Remove previous locks mode=remove_previous Removes any other locks that match the name that you specify. If any matching locks are found in the previous version of the secret, those locks are deleted when your new lock is created.<br><br>For example, suppose that the previous version of your secret contains a lock lock-x.
Vault API 

If you're already using the HashiCorp Vault HTTP API, you can use its API format and guidelines to interact with IBM Cloud® Secrets Manager.

To use the standard REST API for Secrets Manager, check out the [Secrets Manager API reference](https://cloud.ibm.com/apidocs/secrets-manager/secrets-manager-v2).



 Overview 

Secrets Manager uses a custom version of open source HashiCorp Vault. This custom version adds the IBM Cloud IAM Auth method and a set of secrets engines to support operations in Secrets Manager for various secret types.

All operations follow the REST API standards that are available for the Vault HTTP APIs. For more information about how to authenticate and use the Vault HTTP APIs, check out the [Vault documentation](https://developer.hashicorp.com/vault/api-docs/index).

Secrets Manager limits Vault access to only specific paths that help you to work with secrets and log in to your instance. All other paths return an HTTP 403 Forbidden response status code. Plug-ins and other components that are offered by the open source Vault community might not be accessible by Secrets Manager. For more information, see the [FAQs](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-faqsfaq-differences-vault).



 Endpoint URLs 

To access Secrets Manager by using the Vault APIs, use the dedicated endpoint URL that is unique to your Secrets Manager service instance.

The following table lists the endpoint URLs by region that can be used to interact with the Vault APIs.

Public endpoints

Private endpoints



Table 1. Public endpoints for interacting with Secrets Manager by using the native Vault APIs

 Region Endpoint URL 

 Dallas https://{instance_ID}.us-south.secrets-manager.appdomain.cloud 
 Frankfurt https://{instance_ID}.eu-de.secrets-manager.appdomain.cloud 
 London https://{instance_ID}.eu-gb.secrets-manager.appdomain.cloud
Comparison between Secrets Manager and related IBM Cloud services 

With IBM Cloud, you can choose from various secrets management and data protection offerings that help you to protect your sensitive data and centralize your secrets. If you need to integrate general-purpose secrets to authenticate your apps, you can use Secrets Manager to create

dynamic secretsand manage their lifecycle. But for other application secrets, such as encryption keys, your business might require a higher level of control that relies on highly secure, customer-controlled cryptographic hardware.

For example, consider the following scenarios and how they map to secrets management offerings and data protection offerings in IBM Cloud.

Zoom

![The image describes three use cases for secrets management and how they map to available services in IBM Cloud. The content is explained fully in the surrounding text.](https://cloud.ibm.com/docs-content/v1/content/991f60ddbe3ab0a9aa69481a07a0a73b359fa329/secrets-manager/images/secrets-mgmt-options.svg)

Figure 1. Secrets management use cases



 Which data protection service is best for me? 

The following table lists the different offerings that you can use with IBM Cloud to protect your application secrets.



Table 1. Secrets management and data protection scenarios

 Scenario What to use 

 As a DevOps team contributor, you need to create, lease, and manage API keys, credentials, database configurations, and other secrets for your services and applications. With [Secrets Manager](https://cloud.ibm.com/docs/secrets-manager), you can manage secrets of various types in a dedicated instance. 
 You need to generate, renew, and manage SSL/TLS certificates for your deployments. You can also manage your SSL/TLS certificates and private keys in dedicated instance of [Secrets Manager](https://cloud.ibm.com/docs/secrets-manager). 
 You need to create and manage encryption keys that are backed by FIPS 140-2 Level 3 validated hardware.
Secrets in particular can take up a lot of storage on the local node, so plan accordingly.

Both resources define key-value pairs, but you use them for different situations.

Configmap
: Provide non-sensitive configuration information for workloads that are specified in a deployment. You can use configmaps in three main ways.



* File system: You can mount an entire file or a set of variables to a pod. A file is created for each entry based on the key name contents of the file that are set to the value.
* Environment variable: Dynamically set the environment variable for a container spec.
* Command-line option: Set the command-line option that is used in a container spec.



Secret
: Provide sensitive information to your workloads, such as follows. Other users of the cluster might have access to the secret, so be sure that you know the secret information can be shared with those users.



* Personally identifiable information (PII: Store sensitive information such as email addresses or other types of information that are required for company compliance or government regulation in secrets.
* Credentials: Put credentials such as passwords, keys, and tokens in a secret to reduce the risk of accidental exposure. For example, when you [bind a service](https://cloud.ibm.com/docs/openshift?topic=openshift-service-binding) to your cluster, the credentials are stored in a secret.



Want to make your secrets even more secured? Ask your cluster admin to [enable a key management service provider](https://cloud.ibm.com/docs/openshift?topic=openshift-encryptionkeyprotect) in your cluster to encrypt new and existing secrets.





 How can I make sure that my app has the correct resources? 

When you [specify your app YAML file](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_appsapp_yaml), you can add Kubernetes functionalities to your app configuration that help your app get the correct resources.
Use the following commands to add a static secret, such as a user credential or an arbitrary secret, to your Secrets Manager instance. Allowable values for SECRET_TYPE are: arbitrary,imported_cert, [kv](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-vault-manage-kv-cli), private_cert, public_cert, and username_password.

Create a secret in the default secret group.

vault write [-format=FORMAT] ibmcloud/SECRET_TYPE/secrets name=NAME [description="DESCRIPTION"] [username=USERNAME] [password=USERNAME] [payload=DATA] [expiration_date=EXPIRATION] [certificate=CERTIFICATE_DATA] [private_key=PRIVATE_KEY_DATA] [intermediate=INTERMEDIATE_CERTIFICATE_DATA] [ca=CA_CONFIGURATION_NAME] [dns=DNS_CONFIGURATION_NAME] [key_algorithm=KEY_ALGORITHM] [labels=LABEL,LABEL]

Create a secret in a specified secret group.

vault write [-format=FORMAT] ibmcloud/SECRET_TYPE/secrets/groups/SECRET_GROUP_ID name=NAME [description="DESCRIPTION"] [username=USERNAME] [password=USERNAME] [payload=DATA] [expiration_date=EXPIRATION] [certificate=CERTIFICATE_DATA] [private_key=PRIVATE_KEY_DATA] [intermediate=INTERMEDIATE_CERTIFICATE_DATA] [ca=CA_CONFIGURATION_NAME] [dns=DNS_CONFIGURATION_NAME] [key_algorithm=KEY_ALGORITHM] [labels=LABEL,LABEL]



 Prerequisites 

You need the [Writer service role](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-iam) to create secrets.





 Command options 

name
: The human-readable alias that you want to assign to the secret. Required.

description
: An extended description to assign to the secret.

expiration_date
: The expiration date that you want to assign to the secret. Supported for the arbitrary and username_password secret types.