vania-janet/multiturn-rag-retrieval-data huggingface dataset:
"last_seq": "10-g1AAAACbeJzLY"
}

The since parameter is used to define where in the changes feed you want to start from:

since=0
: The beginning of the changes feed.

since=now
: The end of the changes feed.

since=<a last seq token>
: From a known place in the changes feed.

At face value, following the changes feed seems as simple as chaining _changes API calls together. Then, IBM Cloudant passes the last_seq from one changes feed response into the next request's since parameter. But some subtleties to the changes feed need further discussion.
* Why does the changes feed deliver each change at least one time?

The IBM Cloudant Standard changes feed promises to return each document at least one time, which isn't the same as promising to return each document only one time. Put another way, it is possible for a consumer of the changes feed to see the same change again, or indeed a set of changes repeated.

A consumer of the changes feed must treat the changes idempotently. In practice, you must remember whether a change was already dealt with before you trigger an action from a change. A naive changes feed consumer might send a message to a smartphone on every change received. 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.
Options:
--sortby TEXT Column to sort by
--columns TEXT Columns to display. Options: ID, Username, Account ID,
Capacity (GB), Hardware ID, Guest ID, Host ID
-h, --help Show this message and exit.





 Viewing the replication history in the UI 

To view the Replication history, click Manage on the main menu bar. Select Account, and scroll to the Audit Log. The Storage Replication Events list contains the names of the volume, a description of the replication event and the timestamp of the event.





 Editing the Replication Schedule in the UI 

The replication schedule is based on an existing snapshot schedule. To change the replica schedule from Hourly to Daily or Weekly or vice versa, you must cancel the replica volume and set up a new one.

However, if you want to change the time of day when your Daily replication occurs, you can adjust the existing schedule on the active volume.



1. On the active volume details page, click Actions![Actions icon](https://cloud.ibm.com/docs-content/v1/content/04e9937a86546143babfc65ea21fdd4ea2d12d13/icons/action-menu-icon.svg).
2. Select Edit Snapshot Schedule.
3. Look in the Snapshot frame under Schedule to determine which Daily schedule you're using for replication. Change the schedule that you want.
4. Click Save.







 Deleting an existing replica file share in the UI 

You can cancel replication either immediately or on the anniversary date, which causes billing to end.



1. Click the volume from the File Storage for Classic page.
2. Click Actions![Actions icon](https://cloud.ibm.com/docs-content/v1/content/04e9937a86546143babfc65ea21fdd4ea2d12d13/icons/action-menu-icon.svg).
3. Select Delete Replica.
4. Select when to cancel. Choose Immediately or Anniversary Date, and click Continue.
You can use the JSON editor for the slot to reformat the time value as you save it so it uses the hour:minutes AM/PM format instead:

{
"context":{
"time": "<? @sys-time.reformatDateTime('h:mm a') ?>"
}
}

See [Expression language methods](https://cloud.ibm.com/docs/assistant?topic=assistant-dialog-methods) for other reformatting ideas.





 Dealing with zeros 

Using @sys-number in a slot condition is helpful for capturing any numbers that users specify in their input. However, it does not behave as expected when users specify the number zero (0). Instead of treating zero as a valid number, the condition is evaluated to false, and your assistant prompts the user for a number again. To prevent this behavior, check for an @sys-number mention that is greater than or equal to zero in the slot condition.

To ensure that a slot condition that checks for number mentions deals with zeros properly, complete the following step:



1. Add @sys-number >= 0 to the slot condition field, and then provide the context variable name and text prompt.

What you check for in the input is also what is saved in the slot context variable. However, in this case, you want only the number (such as 5) to be saved. You do not want to save 5 > = 0. To change what is saved, you must edit the value of the context variable.
2. Open the slot to edit it by clicking the Customize slot![Customize slot](https://cloud.ibm.com/docs-content/v1/content/417db917d18067d9dcc4cf2612564a9a87c3ddc8/assistant/images/edit-slot.png) icon. From the Options!
For example, to update the network ACL used by a subnet use the PATCH /v1/subnets/{subnet_id}?version=$version&generation=1 -d '{ "network_acl":{ "id": “{network_acl_id}” } }’ API.

The following request would be invalid because “networkacl” is not a valid field, PATCH /v1/subnets/{subnet_id}?version=$version&generation=1 -d '{ "networkacl":{ "id": “{network_acl_id}” } }’

Refer to the [API documentation](https://cloud.ibm.com/apidocs/vpc-on-classic) for acceptable values.





 invalid_state 

Message: An action was requested on a resource which is not supported at the current status of the resource.

If the resource is an instance:



1. A reboot operation may already be in progress for the instance. Refer to [actions allowed](https://cloud.ibm.com/docs/vpc-on-classic?topic=vpc-on-classic-troubleshooting-your-ibm-cloud-vpcerror-409-conflict-invoke-action), depending on the status of the instance.
2. While the status of the instance is pending you cannot perform the following actions:



* delete the instance
* attach a volume to the instance
* detach a volume from the instance
* update the instance





Try your action again later. If the status of the resource does not change, [contact support](https://cloud.ibm.com/docs/vpc-on-classic?topic=vpc-on-classic-getting-help-and-support).

If the resource is an image:

While the status of the instance is deleting you cannot perform the following actions: * patch the image * delete the image

Do not make the request again. Deletion of the image will complete in its own time. Once deletion is complate, all requests on that image will fail with the error not_found instead.
Problems can occur if a job is scheduled to run twice in a short period. In particular, try to avoid overlapping schedules for SQL Server database jobs in the same instance. Simultaneous backups in the same SQL Server instance are supported, but are not recommended.



1. In the View/Add Schedule dialog box, click Add Schedule.
2. In the new schedule row, in the Retention list, click a retention type.
3. Select the Backup Type:



* To back up each database from the point in time when the backup starts, click Full.
* To back up each database and its transaction logs from the point in time when the backup starts, click Full with transaction logs.
* To back up the database transaction logs only from the point in time when the backup starts, click Transaction logs only. When Transaction Logs only is selected, the entire database and its transaction logs are backed up when the job first runs. In subsequent backups, only the transaction logs are backed up.



After a transaction log backup, logs are marked for truncation. If you also back up databases by using another tool (for example, native SQL Server backup), use only one tool for truncating logs. Transaction logs can be backed up for databases only when they use the full or bulk-logged recovery model.
4. In the Schedule box, click the arrow.
5. In the Configure Job Schedule dialog box, choose one of the following options.



* To run the backup on specific days each week, in the Schedule View list, click Days of Week. Select the days when you want to run the job. Then, use the At field to specify the time when you want to run the job.
* 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.
From the domain mapping page, you can view information about the remaining days until the certificate expires.



 Updating a custom domain mapping from the console 

Suppose the custom domain mapping for www.example.com has a certificate that expires soon. You can update the domain mapping from the console to use an updated certificate or even replace the TLS secret for the mapping. You can also update your domain mapping to point to a different application in your project.



1. From the [Code Engine Projects page](https://cloud.ibm.com/codeengine/projects), go to your project.
2. From the Overview page, click Domain mappings.
3. From the Domain mappings page, click the Actions icon ![Actions](https://cloud.ibm.com/docs-content/v1/content/ad5f41087138b4b1bb795e3b5b0661ac5a105cbd/icons/action-menu-icon.svg) > Edit to edit the mapping. Or, you can click in the row of your defined custom domain to update the mapping.
4. From the Update a domain mapping page, you can change the application that is associated with this domain mapping, or you can replace or update the TLS secret for this mapping.
5. Click Update to save your changes.



After you update the mapping, you can view the list of domain mappings for the latest changes.





 Updating a custom domain mapping with the CLI 

To update a custom domain mapping, use the [ibmcloud ce domainmapping update](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-domainmapping-list) command.

Suppose the custom domain mapping for www.example.com has a certificate that expires soon. You can update the domain mapping to use an updated certificate or even replace the TLS secret for the mapping with the --tls-secret option. You can also update your domain mapping to point to a different application in your project with the --target option.
ID: abcdefgh-abcd-abcd-abcd-fb6be2347a14
Project Name: myproject
Project ID: 01234567-abcd-abcd-abcd-abcdabcd1111
Age: 18s
Created: 2021-03-14T13:33:53-05:00

Destination: App:kapp
Schedule: /2 * * * 
Time Zone: UTC
Ready: true

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

When Ready is true, then the cron subscription is ready to trigger events per the specified schedule.







 ibmcloud ce subscription cron list 

List all cron event subscriptions in a project.

ibmcloud ce subscription cron list [--output OUTPUT] [--quiet] [--sort-by SORT_BY]



 Command Options 

--output, -o
: Specifies the format of the command output. Valid values are json, yaml, jsonpath=JSONPATH_EXPRESSION, and jsonpath-as-json=JSONPATH_EXPRESSION. Use jsonpath to specify the path to an element of the JSON output. This value is optional.

--quiet, -q
: Specify this option to reduce the output of the command. This value is optional. The default value is false.

--sort-by, -s
: Specifies the column by which to sort the list. Valid values are name and age. This value is optional. The default value is name.





 Example 

ibmcloud ce subscription cron list





 Example output 

Listing cron sources...
OK

Name Age Ready Destination Schedule Data
mycronevent 96m true http://myapp.cd4200a7-5037.svc.cluster.local /2 * * * 







 ibmcloud ce subscription cron update 

Update a cron event subscription.
Run the [ibmcloud resource service-instance-update](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_commands_resourceibmcloud_resource_service_instance_create) command:

ibmcloud resource service-instance-update NAME --service-plan-id RESOURCE_PLAN_ID

Where



* NAME is the name of the instance
* service-plan-id indicates the type of plan.
* RESOURCE_PLAN_ID is the ID of the plan that you want to set. To get the service plan IDs, see [Service plans](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-service_plans).





For example, to change the service plan of an instance to the 30 days retention plan, run the following command:

ibmcloud resource service-instance-update logging-instance-01 deda35aa-662b-4b06-9f6e-05e0b55cc577
Deprecated products are removed after 90 days. For more information, see [Publishing your software to the IBM Cloud catalog](https://cloud.ibm.com/docs/sell?topic=sell-sw-publish).

IBM Cloud can suspend your product if there's an issue that you need to address. Any updates that you need to make are shared by email.





 Suspending your product from the IBM Cloud catalog by using the API 

You can programmatically suspend your product by calling the [Partner Center Sell API](https://cloud.ibm.com/apidocs/partner-center-sellsuspend-product) as shown in the following sample request. Specify reason to provide details about why you want to suspend your published product.

curl --request POST --url https://product-
lifecycle.api.cloud.ibm.com/openapi/v1/products/9fab83da-98cb-4f18-
a7ba-b6f0435c9673/suspend --header 'Authorization: Bearer TOKEN' --data '{
"reason": "There is a bug in the operation of the product that must be fixed. To fix the error, I want to suspend my product."
}'
The status of the registration is Pending until the registration is complete, at which point the status changes to Complete.



Registration times are not controlled internally, and they can vary based on the region in which the subnet is located.





 Updating the registration information for a registered subnet 

After a subnet completes its initial RIR registration, you can update the registration information for the subnet. Follow these steps to update the RIR registration for a subnet.



1. From your browser, open the [IBM Cloud console](https://cloud.ibm.com/) and log in to your account.
2. From the dashboard, click the Menu icon ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/icons/icon_hamburger.svg) and select Classic Infrastructure.
3. Select Network > IP Management > RIR Registration.
4. Select Edit Registration from the Actions list for a registered subnet. An Update Subnet window appears, displaying the current registration information.
5. Select the Person Record you would like to use for the registration. For more information, see [Creating an RIR registration with person details](https://cloud.ibm.com/docs/subnets?topic=subnets-rircreating-rir-registration-person-details).
6. Click Register to update the RIR registration. The status of the registration is Pending until the registration update is complete, at which point the status changes to Complete.



Registration update times are not controlled internally, and they can vary based on the region in which the subnet is located.





 Creating an RIR registration with person details 

Several person records can be maintained on your account for use across multiple subnet registrations. A subnet registration must be associated to a single person record before attempting to inform the registrar of the associated network assignment. If invalid or poorly formatted data is present in the chosen person record, according to the targeted registrar, the registration request is rejected.

Registrar entities maintain different rules for formatting personal data, so it is possible for a person record to be successfully registered with one registrar and to be rejected by another.



 Person record validation rules
"lastUpdateDate": "2020-06-18T20:34:39Z",
"keyVersion": {
"id": "c024c2b3-2093-46e5-aabb-fdf8cbc14e44",
"creationDate": "2020-06-18T20:34:39Z"
},
"extractable": false,
"state": 1,
"crn": "crn:v1:bluemix:public:kms:us-south:a/ea998d3389c3473aa0987652b46fb146:a192d603-0b8d-452f-aac3-f9e1f95e7411:key:c024c2b3-2093-46e5-aabb-fdf8cbc14e44"
}

 update the policy and rotate the key every 2 months
$ ibmcloud kp key policy-update rotation $KEY_ID -m 2 --output json

{
"createdBy": "user id ...<redacted>...",
"creationDate": "2020-06-18T20:35:41Z",
"crn": "crn:v1:bluemix:public:kms:us-south:a/ea998d3389c3473aa0987652b46fb146:a192d603-0b8d-452f-aac3-f9e1f95e7411:policy:06a40fd6-6fd7-460a-87d7-8388fc1be057",
"lastUpdateDate": "2020-06-18T20:35:41Z",
"updatedBy": "user id ...<redacted>...",
"rotation": {
"interval_month": 2
}
}

 list the policies
The next step is to create a document that resolves the conflicts, and update the database with it.

See the following example document that merges changes from the two conflicting revisions:

{
"_id": "74b2be56045bed0c8c9d24b939000dbe",
"_rev": "3-daaecd7213301a1ad5493186d6916755",
"name": "Samsung Galaxy S4",
"description": "Latest smartphone from Samsung",
"price": 600
}





 Delete old revisions 

Finally, you delete the old revisions by sending a DELETE request to the URLs with the revision you want to delete.

See the following example request to delete an old document revision by using HTTP:

DELETE https://$ACCOUNT.cloudant.com/products/$_ID?rev=2-61ae00e029d4f5edd2981841243ded13

See the following example request to delete an old document revision:



* Curl
* Java
* Python
* Go
* Node



curl -H "Authorization: Bearer $API_BEARER_TOKEN" -X DELETE "$SERVICE_URL/events/0007241142412418284?rev=2-9a0d1cd9f40472509e9aac6461837367"

import com.ibm.cloud.cloudant.v1.Cloudant;
import com.ibm.cloud.cloudant.v1.model.DeleteDocumentOptions;
import com.ibm.cloud.cloudant.v1.model.DocumentResult;

Cloudant service = Cloudant.newInstance();

DeleteDocumentOptions documentOptions =
new DeleteDocumentOptions.Builder()
.db("events")
.docId("0007241142412418284")
.rev("2-9a0d1cd9f40472509e9aac6461837367")
.build();
Manually approving change requests 

You can either approve change requests manually or automatically.

By default, standard change requests are created and if all of the required compliance checks pass, the deployment readiness is set to true. When a change request is of the standard type and the deployment readiness is set to true, it is automatically approved.

If one or more compliance checks fail, deployment readiness is set to false, the continuous deployment pipeline breaks, and the deployment stops because of the unapproved change request.

You can deploy a manually approved change request by adding an emergency label to the promotion pull request or by providing a manually pre-approved (with label status_approved) change request. Take either of the following steps:



 Step 1: Adding an emergency label to promotion PR 

If you need to deploy emergency changes immediately, you can use emergency mode. When you promote a change, add an emergency label to the promotion pull request to prompt the continuous deployment pipeline to create an emergency change request. Emergency change requests allow deployment to continue even if the approval is missing.

Use the emergency mode sparingly and with caution.

You can set the value of the emergency label (default: EMERGENCY) that the continuous deployment pipeline looks for on the promotion pull request when you create the toolchain.

Zoom

![Emergency label](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/emergency-label-at-creation.png)

Figure 1. Emergency label

You can also change the value of the emergency label from the pipeline's environment variables:

Zoom

![Emergency label variable](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/emergency-label-env.png)

Figure 2. Emergency label variable
API change log 

Find a summary of the latest changes, improvements, and updates for the IBM Cloud® Code Engine API plug-in. Changes to existing API versions are designed to be compatible with existing client applications.



 API versioning 

API requests require a version parameter that takes the date in the format version=YYYY-MM-DD. Send the version parameter with every API request.

When the API is changed in a way that is not compatible with previous versions, a new minor version is released. To take advantage of the changes in a new version, change the value of the version parameter to the new date. If you're not ready to update to that version, don't change your version date.



 Active version dates 

The following table shows the service behavior changes for each version date. Switching to a later version date will activate all changes introduced in earlier versions.



Changes in the IBM Cloud Code Engine API

 Version date Summary of changes 

 2022-Dec-09 Version 2.0.0 
 2021-Mar-31 Version 1.0.0 









 22 June 2023 

Added support for service binding operations in the API.
: 

* See [List bindings API](https://cloud.ibm.com/apidocs/codeengine/v2list-bindings).



: 

* See [Create a binding API](https://cloud.ibm.com/apidocs/codeengine/v2create-binding).



: 

* See [Get a binding API](https://cloud.ibm.com/apidocs/codeengine/v2get-binding).



: 

* See [Delete a binding API](https://cloud.ibm.com/apidocs/codeengine/v2delete-binding).



Added support for service access secrets which are required for service binding operations. Specify to create service access secrets with the format field and specify the details of service access secrets with the service_access field.
: 

* See [Create a secret API](https://cloud.ibm.com/apidocs/codeengine/v2create-secret).







 30 May 2023
Version control software tracks code modifications, and if needed, allows you to switch back to previous versions of the code.

Cloud Functions can access only the most recently used version that was provided when you created or updated an action and stores only the latest version of action code.





 Naming conventions 

If you do not have a version control system, you can create a naming scheme for your actions to track multiple versions of an action. For example, consider appending a three-part semantic versioning number to the action name, such as myAction_1.0.1.

To use these different actions versions in triggers, assign the appropriate version of an action to the trigger by using the [ibmcloud fn rule create](https://cloud.ibm.com/docs/openwhisk?topic=cloud-functions-cli-plugin-functions-clicli_rule_create) or the [ibmcloud fn rule update](https://cloud.ibm.com/docs/openwhisk?topic=cloud-functions-cli-plugin-functions-clicli_rule_update) CLI commands.

Example

ibmcloud fn rule update myRule myTrigger myAction_1.0.1