vania-janet/multiturn-rag-retrieval-data huggingface dataset:
const policyRule = {
operator: 'and',
conditions: [
{
key: '{{environment.attributes.current_time}}',
operator: 'dateTimeGreaterThanOrEquals',
value: '2022-12-23T00:00:00+00:00',
},
{
key: '{{environment.attributes.current_time}}',
operator: 'dateTimeLessThanOrEquals',
value: '2022-12-23T23:59:59+00:00',
},
],
}
const policyPattern = 'time-based-conditions:once'
const params = {
type: 'access',
subject: policySubject,
control: policyControl,
resource: policyResource,
rule: policyRule,
pattern: policyPattern,
};

try {
const res = await iamPolicyManagementService.v2CreatePolicy(params);
examplePolicyId = res.result.id;
console.log(JSON.stringify(res.result, null, 2));
} catch (err) {
console.warn(err)
}

Temporary policies, which use the pattern time-based-conditions:once, aren't automatically removed. To avoid reaching the policy limit in the account, administrators can remove the policy manually after it expires.

For more information about time-based conditions for access policies, see [Conditions in access policies](https://cloud.ibm.com/docs/account?topic=account-iam-condition-properties&interface=uipolicy-condition-properties).





 Creating a recurring time-based condition 

You can assign recurring access at a weekly cadence. You might want to give users access to account resources during only their working hours.

Complete the following steps to assign an access policy with a recurring time-based condition:



1. In the IBM Cloud console, go to Manage > Access (IAM)
The command returns the following output:

updated_time 2021-02-02T18:06:03Z
description Discount given to IBM Indian employees
enabled_value true
disabled_value false
segment_rules <Array>
created_time 2021-02-02T17:52:46Z
name Indian IBMers
type BOOLEAN
enabled true
collections <Array>









 ibmcloud ac feature update-values 

You can update values of a feature (This method allows the update of feature name, feature enabled_value, feature disabled_value, tags, description, and feature segment rules, however this method does not allow toggling the feature flag and assigning feature to a collection.), by using the command:

ibmcloud ac feature update-values {--file FILE-PATH | --environment_id ENVIRONMENT_ID --name NAME --feature_id FEATURE_ID --description DESCRIPTION --enabled_value ENABLED_VALUE --disabled_value DISABLED_VALUE --tags TAGS --segment_rules SEGMENT_RULES}



 Command options 

--environment_id ENVIRONMENT_ID
: Environment ID

--name NAME
: Feature name. Required field - input either as a flag or from file.

--feature_id FEATURE_ID
: Feature ID. Required field - input either as a flag or from file.

--description DESCRIPTION
: Description of the feature. Required field - input either as a flag or from file.

--enabled_value ENABLED_VALUE
: Value of the feature when it is enabled. Required field - input either as a flag or from file.

--disabled_value DISABLED_VALUE
: Value of the feature when it is unavailable. Required field - input either as a flag or from file.

--tags TAGS
: Tags associated with the feature. Required field - input either as a flag or from file.

--segment_rules SEGMENT_RULES
: Specify the targeting rules that are used to set different values for different segments.

--file FILE
: Input through the file. File format Supported - JSON





 Example
"value": "IBMid-550000HFVV"
}
]
}
}



For more information about time-based conditions for access policies, see [Conditions in access policies](https://cloud.ibm.com/docs/account?topic=account-iam-condition-properties&interface=uipolicy-condition-properties).





 Creating a recurring time-based condition by using the API 

You can assign recurring access at a weekly cadence. You might want to give users access to account resources during only their working hours.

The following examples show you how to create a recurring time-based condition for a user. The policy assigns access during working hours Monday through Friday as an Editor for all Account Management Services.



* Java
* Python
* Go
* Node



V2PolicyAttribute subjectAttribute = new V2PolicyAttribute.Builder()
.key("iam_id")
.value(EXAMPLE_USER_ID)
.operator("stringEquals")
.build();

V2PolicyBaseSubject policySubject = new V2PolicyBaseSubject.Builder()
.addAttributes(subjectAttribute)
.build();

V2PolicyAttribute accountIdResourceAttribute = new V2PolicyAttribute.Builder()
.key("accountId")
.value(exampleAccountId)
.operator("stringEquals")
.build();

V2PolicyAttribute serviceNameResourceAttribute = new V2PolicyAttribute.Builder()
.key("serviceName")
.value("iam-groups")
.operator("stringEquals")
.build();

V2PolicyBaseResource policyResource = new V2PolicyBaseResource.Builder()
.addAttributes(accountIdResourceAttribute)
---------------------------------------------------------------------------------------------------------------------------------------------------

 set a rotation policy of 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
}
}
This parameter is for the promotion pull request. This value holds the assignee of the change request. This should be a functional id or an email who will be assigned to the change request in the change management system.





 backout-plan 

This parameter is for the promotion pull request. Plan of how the change will be rolled back in case of a failure. By default it is empty.





 branch 

This is an optional parameter for the CI pipeline. It determines which branch we pull the code from the app repository. By default, it's master.





 change-management-duration 

This is an optional parameter for the CD pipeline. The value of it will be the created change request's maintenance duration. By default it's 30 min.





 change-request-id 

This is an optional parameter for the CD pipeline. By providing a change request ID, the pipeline will skip the creation of a new change request and will use the provided change request. If this parameter is set to notAvailable or left empty, a change request is automatically created by the continuous deployment pipeline. By default it's notAvailable.





 cluster 

This parameter holds the name of the cluster in the CD pipeline, which is used for the Docker deploy. This parameter is required for the example app.





 cluster-name 

This parameter holds the name of the cluster in the CI pipeline, which is used for the Docker deploy. This parameter is required.





 cluster-region 

This is a parameter for the CD pipeline. The IBM Cloud region that hosts the cluster. This is a required parameter for the example app.





 compliance-baseimage 

This parameter holds the version of the compliance-baseimage. If you want to use something other than our latest image, you can use this parameter.

Example: icr.io/continuous-delivery/toolchains/devsecops/baseimage:some-other-tag





 custom-exempt-label 

This is an optional parameter for the CI and CC pipelines. If you marked an incident issue permanently exempted with a custom label, then this parameter should hold the value of the custom label.





 customer-impact
To update your service plan after you create an instance, see [Updating your service plan](https://cloud.ibm.com/docs/billing-usage?topic=billing-usage-changing).





 Upgrading a Secrets Manager instance to the Standard plan 

When your Trial instance expires, you lose access to your secrets, and integrations. To preserve your data, and prevent any disruptions in your workflow, you must upgrade to the Standard plan before your Trial plan expires. Follow the steps to [update your pricing plan](https://cloud.ibm.com/docs/billing-usage?topic=billing-usage-changing&interface=ui). You can use the UI, API, and CLI to complete this process.
* swift:4.1 (disabled)
* swift:4.2 (disabled)



For more information about supported and disabled runtimes, see [Available images and runtimes per region](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-runtimesruntimes_per_region).





 JavaScript runtimes 

By default, all Node.js actions are executed in a version 16 environment.

Node.js version 12 is deprecated and is planned to be removed soon. To continue running your actions, you must update any Node.js version 12 actions to a higher runtime version. For more information, see the [Node.js release schedule](https://github.com/nodejs/Release).

Node.js version 10 is deprecated and is planned to be removed soon. To continue running your actions, you must update any Node.js version 10 actions to a higher runtime version. For more information, see the [Node.js release schedule](https://github.com/nodejs/Release).

Node.js version 8 is deprecated and is planned to be removed soon. To continue running your actions, you must update any Node.js version 8 actions to a higher runtime version. For more information, see the [Node.js release schedule](https://github.com/nodejs/Release).



Table 1. Node.js versions

 Kind Node.js version Description Change log 

 nodejs:16 [16.x](https://nodejs.org/docs/latest-v16.x/api/) By default, all Node.js actions are executed in a version 16 environment. [CHANGELOG.md](https://github.com/ibm-functions/runtime-nodejs/blob/master/nodejs16/CHANGELOG.md).
Deprecating a private product 

To permanently delete a private product or version, deprecate it first. Your product remains available for use during a 90-day deprecation period, and is removed after 90 days.

Deprecating your product or version will permanently delete it for use after 90 days. If you want to temporarily remove your product, suspend it instead.

Complete the following steps to deprecate your product or version:



1.  Click Manage > Catalogs > Private catalogs in the IBM Cloud® console.
2.  Select the private catalog where your product is located.
3.  Select your product.
4.  Optionally, if you want to deprecate a specific version of your software, select that version from the list.

If your software has only one published version, and you deprecate that version, the entire product is deprecated.
5.  Open the Actions menu and select Deprecate.
6.  Optionally, you can include more details, like a link to a deprecation announcement.
7.  Click Deprecate.



You can also deprecate your product or version by clicking the Actions icon ![Actions icon](https://cloud.ibm.com/docs-content/v1/content/4d8c6eec891cff72b666dc24bd3211810c77fb42/icons/actions-icon-vertical.svg) and selecting Deprecate for that product or version.

After you deprecate your product or version, you have 90 days to restore it to its last published state before it is removed for use. After 90 days, your product or version moves to the Archived state in your private catalog in Catalog management.
"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:52:52Z",
"updatedBy": "user id ...<redacted>...",
"rotation": {
"enabled": false,
"interval_month": 3
}
}
---------------------------------------------------------------------------------------------------------------------------------------------------





 Required parameters 



* KEY_ID_OR_ALIAS

The v4 UUID or alias of the key that you want to query. To retrieve a list of your available keys, run the [kp keys](https://cloud.ibm.com/docs/key-protect-cli-plugin?topic=key-protect-cli-plugin-key-protect-cli-referencekp-keys) command.







 Optional parameters 



* -m, --monthly-interval

Set the key rotation interval in months. The rotation interval must be 1 to 12 months.
* -e, --enable or -d, --disable

By default, key rotation policy is enabled.
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.
* Does a feed=continuous changes feed continue to run indefinitely?

No, IBM Cloudant does not guarantee connection duration for a continuous changes feed. It might be regularly disconnected by the server for any number of reasons, which include maintenance, security, or network errors. Code that uses the changes feed must be designed to use a recently saved sequence ID as a since value to make a new request to resume the changes feed after an error or disconnection.
* Why doesn't the changes feed guarantee time-ordering?

If the use case is based on the following statement, then this result cannot be achieved with the IBM Cloudant changes feed.

"Fetch me every document that has changed since a known date, in the order they were written."

The IBM Cloudant database does not record the time as each document change was written. The changes feed makes no guarantees on the ordering of the changes in the feed - they are not guaranteed to be in the order they were sent to the database.

However, you can achieve this use case by storing the date of change in the document body:

{
"_id": "2657",
"type": "order",
"customer": "bob@aol.com",
"order_date": "2022-01-05T10:40:00",
"status": "dispatched",
"last_edit_date": "2022-01-14T19:17:20"
}

And you can create a MapReduce view with last_edit_date as the key:

function(doc) {
emit(doc.last_edit_date, null)
}

This view can be queried to return any documents that are modified on or after a supplied date and time:

/orders/_design/query/_view/by_last_edit?startkey="2022-01-13T00:00:00"
* To run the backup on specific dates each month, click Days of Month in the Schedule View list. On the calendar, select the dates when you want to run the job. Then, use the At field to specify the time when you want to run the job.
* To create a custom schedule, click Custom in the Schedule View list. In the Custom Cycle dialog box, enter a custom schedule. Be sure to follow the format and notation as described.



6. Click Okay. The schedule appears in the Schedule box.
7. In the Compression list, click a compression level for the backup data. Compression levels optimize the volume of data sent against the speed of processing.
8. For deferring, select one of the following options.



* To allow the backup job to run without a time limit, click None in the Deferring list.
* To specify a maximum amount of time that the backup job can run, click Minutes or Hours in the Deferring list. In the adjacent box, type the maximum number of minutes or hours that the job can run.



When you use the deferring option, the backup job doesn't back up any new data after the specified amount of time, even if some data is not backed up. Changes to data that was previously backed up are still backed up, regardless of the amount of time specified.
9. To run the job on the specified schedule, select the Enable checkbox near the end of the row.

If more than one schedule row exists, you can use the Priority arrows to change the order of the schedule rows. Schedules higher in the list have a higher priority than schedules toward the end of the list. If a job is scheduled to run at the same time by multiple schedules, the job runs once at the scheduled time. If the schedules have different retention types, the job runs with the retention type of the schedule that is highest in the priority list.
10. Click Save.







 Protecting SQL databases in AlwaysOn Availability Groups 

You can protect SQL Server databases in AlwaysOn Availability Groups by using the Windows® IBM Cloud Backup for Classic Agent and SQL Server plug-in.
Runtimes 

Your apps can be coded and executed in programming languages such as JavaScript or Python. Many runtimes are available by default with IBM Cloud® Functions.



 Available images and runtimes 

These runtimes (kinds) are available:



Table 1. Supported runtimes

 Language Kind identifier 

 Node.js nodejs:16 (default) 
 Python python:3.11 (default) 
 PHP php:8.1 (default) 
 Go go:1.19 (default) 
 Java java (JDK 8) (default) 



Other languages are supported by using Docker actions.

Runtimes are updated regularly. These updates include security fixes and minor version updates (bug fixes) to the runtime packages. Minor version updates might introduce breaks in compatibility with earlier versions. Runtime updates might impact your actions.

A runtime might also be deprecated, which means that certain runtime components are no longer supported. A deprecated runtime is still available for a certain time after deprecation and your actions continue to be executed as normal. However, you cannot create or update an action with a deprecated runtime from the console. The console marks actions that use a deprecated runtime. Note that you can create and update actions with a deprecated runtime from the CLI, however, it is highly recommended not to use deprecated runtimes.

After a runtime is deprecated, it becomes disabled. The timeframe between deprecated and disabled is not fixed and can vary from a few months to a few years. After a runtime is disabled, actions that use this runtime fail with the error 400, bad request. An action that uses a disabled runtime can still be read and deleted.

Migrate actions that are running on a deprecated or disabled runtime to a different runtime version by updating it. To update the runtime, see [changing action runtime](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-actionsactions_update).

These runtimes (kinds) are deprecated:
Created: 2021-04-13T11:38:50-05:00

Destination Type: job
Destination: myjob
Schedule: /5 * * * 
Time Zone: UTC
Content Type: application/json
Data: { "message": "Hello world!" }
Ready: true

Events:
Type Reason Age Source Messages
Normal FinalizerUpdate 12s pingsource-controller Updated "mycronevent" finalizers

From this output, you can see that the destination job is myjob, the schedule is /5 * * * * (every 5 minutes), and the Ready state is true.

Job runs that are created by subscriptions are deleted after 10 minutes.



 Updating the cron subscription with the CLI (job) 

To update the cron subscription with the CLI, use the [ibmcloud ce subscription cron update](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-subscription-cron-update) command. For example, update the mycronevent subscription to change the schedule to sends an event to an app called myapp every 2 minutes.

ibmcloud ce sub cron update --name mycronevent --schedule '/2 * * * '

To verify that your cron subscription was successfully updated, run the ibmcloud ce sub cron get --name mycronevent command. The schedule for the subscription is updated.

Example output

Getting cron source 'mycronevent'...
OK

Name: mycronevent
ID: abcdefgh-abcd-abcd-abcd-1a2b3c4d5e6f
Project Name: myproject
Project ID: 01234567-abcd-abcd-abcd-abcdabcd1111
Age: 2m21s
Created: 2021-08-31T16:00:49-04:00

Destination Type: job
Destination: myjob
Schedule: /2 * * * 
Time Zone: UTC
Content Type: application/json
Maintenance windows 

Routine maintenance windows are scheduled to ensure that your IBM® Db2® Warehouse on Cloud system receives the latest features, patches, and upgrades. During these maintenance windows, updates are applied automatically without your intervention. For posts of maintenance windows, see [IBM Cloud status: Planned Maintenance](https://cloud.ibm.com/status?component=dashdb&selected=maintenance). We contact you directly if your system specifically needs maintenance.

If you have business situations or conditions that might be impacted by the scheduling of our maintenance windows, open a [support case](https://cloud.ibm.com/unifiedsupport/cases/add) to inform us about your concerns.
* If a service API employs [date-based versioning](https://cloud.ibm.com/docs/api-handbook?topic=api-handbook-changes-overview), stricter enforcement MAY be added for a new version date. If feasible, updated enforcement SHOULD happen in a single version date across the whole service. For large services, an iterative approach where cohesive sections of the API are updated in a series of versioned changes MAY be used.
* If a new major version for a service API is developed, updated robustness best practices MUST be enforced across the new version.



When existing service APIs are extended, new operations and new request headers, request schema properties, and query parameters on existing operations SHOULD adhere to updated robustness best practices with respect to invalid and extraneous input but MAY maintain consistency with existing API features with respect to canonicalization.





 Optimistic locking 

In cases where races between clients could result in unintended resource configurations, optimistic locking through [validator](https://cloud.ibm.com/docs/api-handbook?topic=api-handbook-headersvalidator-headers) and [conditional](https://cloud.ibm.com/docs/api-handbook?topic=api-handbook-headersconditional-headers) headers SHOULD be supported.

In particular, the following operations SHOULD support optimistic locking:



* A PUT operation that wholly replaces an existing resource
* A PATCH operation that supports JSON merge-patch and the mutation of an array field



If specific kinds of requests are deemed particularly dangerous in race conditions, a service MAY require that the client provide an If-Match header.
The following example resource identifies the policy by ID, and you can change the plan's name or its schedule by updating the name or the cron_spec arguments.

resource "ibm_is_backup_policy_plan" "example" {
backup_policy_id = "r138-0521986d-963c-4c18-992d-d6a7a99d115f"
cron_spec = "10 20 * * "
name = "example-backup-policy-plan"
}

The following example is a resource definition that you can use to update the backup plan with fast restore clones in two eu-de zones.

resource "ibm_is_backup_policy_plan" "example" {
backup_policy_id = "r138-0521986d-963c-4c18-992d-d6a7a99d115f"
cron_spec = "10 20 * * "
name = "example-backup-policy-plan"
clone_policy {
zones = ["eu-de-1", "eu-de-2"]
max_snapshots = 4
}
}

For more information about the arguments and attributes, see [ibm_is_backup_policy_plan](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/is_backup_policy_plan).





 Deleting a backup plan or a backup policy with Terraform 

Use the terraform destroy command to conveniently destroy a remote object such as a single backup plan or backup policy. The following example destroys the example-backup-policy-plan.

terraform destroy --target ibm_is_backup_policy_plan.example.id

The following example deletes the example-backup-policy.

terraform destroy --target ibm_is_backup_policy.example.id

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







 Backup policy statuses 

Table 1 defines the statuses for backup policies.