vania-janet/multiturn-rag-retrieval-data huggingface dataset:
You create a secret that expires in 89 days and is scheduled to be automatically rotated in 90 days.



Table 1. Example automated workflow for locking secrets.

 Description of action 

 1 Run an pipeline that obtains the secret from Secrets Manager and deploys it to a Kubernetes cluster so that it can be used by your applications. 
 2 Create locks on the current version of the secret (one lock to for each application or service that uses the secret). 
 3 After 90 days, receive a notification from Event Notifications that your secret was rotated. In response to the notification, run a pipeline to get the latest secret version and deploy it to your cluster. 
 4 Run another pipeline that 1) verifies that the new secret version was picked up by the service pods in your cluster, and 2) removes both locks on the previous version of the secret in Secrets Manager. 
 5 After two days, the previous version of the secret expires and is safely deleted from your instance. The next periodic rotation cycle repeats steps 2 - 4.
If your assistant jumps to the earlier node and checks its condition, it is likely to return false because the same user input is being evaluated that triggered the current node last time through the dialog. Your assistant will go to the next sibling or back to root to check the conditions on those nodes, and will likely end up triggering this node again, which means the process will repeat itself.
* Response: If the statement targets the response section of the selected dialog node, it is run immediately. That is, the system does not evaluate the condition of the selected dialog node; it processes the response of the selected dialog node immediately.

Targeting the response is useful for chaining several dialog nodes together. The response is processed as if the condition of this dialog node is true. If the selected dialog node has another Jump to action, that action is run immediately, too.
* Wait for user input: Waits for new input from the user, and then begins to process it from the node that you jump to. This option is useful if the source node asks a question, for example, and you want to jump to a separate node to process the user's answer to the question.







 Next steps 



* Be sure to test your dialog as you build it. For more information, see [Testing the dialog](https://cloud.ibm.com/docs/assistant?topic=assistant-dialog-tasks).
* For more information about ways to address common use cases, see [Dialog building tips](https://cloud.ibm.com/docs/assistant?topic=assistant-dialog-tips).
* For more information about the expression language that you can use to improve your dialog, such as methods that reformat dates or text, see [Expression language methods](https://cloud.ibm.com/docs/assistant?topic=assistant-dialog-methods).



You can also use the API to add nodes or otherwise edit a dialog. See [Modifying a dialog using the API](https://cloud.ibm.com/docs/assistant?topic=assistant-api-dialog-modify) for more information.
[Edit icon](https://cloud.ibm.com/docs-content/v1/content/4d8c6eec891cff72b666dc24bd3211810c77fb42/icons/edit-tagging.svg) on the Access token tile.
3. Enter the time limit in minutes. An access token can be valid for up to 60 minutes.
4. Click Save.







 Managing refresh token expiration 

When available, this credential is used to get a new access token without reauthentication. This token isn't sent to APIs and is used only to get new access tokens.

To update your refresh token expiration setting, complete the following steps:



1. In the IBM Cloud® console, click Manage > Access (IAM), and select Settings.
2. From the Login session section, click the Edit icon ![Edit icon](https://cloud.ibm.com/docs-content/v1/content/4d8c6eec891cff72b666dc24bd3211810c77fb42/icons/edit-tagging.svg) on the Refresh token tile.
3. Enter the time limit in hours. A refresh token can be valid for up to 72 hours (3 days).
4. Click Save.







 Determining when sessions are created 

Sessions are created when a user logs in to the IBM Cloud® CLI or IBM Cloud® console. For example, if you create a user API key and use it for the IBM Cloud® CLI, this generates a login session. However, if you use the same API key to create a token for API calls, like [creating an IAM access token for a user or service ID](https://cloud.ibm.com/apidocs/iam-identity-token-apigettoken-apikey), this does not generate a session.

Tokens expiration settings apply only if there is no connected login session.
That content is then cached for the TTL duration specified for the content. If a user request is received after the TTL has expired, the Edge server reaches out to the origin host to fetch the content. If the origin server cannot be reached for some reason (for instance, the origin host is down, or there is a network issue), the Edge server serves the expired (stale) content to the request. This feature is supported by Akamai and cannot be turned off.





 Support for multiple origins with distinct paths 

In certain cases, you might want to deliver certain content from a different origin server. For example, you might want certain photos or videos that are served from different origin servers. IBM Cloud CDN provides the option to set up multiple origin servers with multiple paths. This allows flexibility with regards to how and where the data is stored.

The path that is specified for the origin server must be unique regarding the CDN. The origin server itself does not need to be unique.





 Time to Live (TTL) 

Time to Live indicates the amount of time (in seconds) the Edge server retains the cached content for that particular file or directory path. When a CDN is first created, a global TTL is created for path /* with a default time of 3600 seconds. The minimum value for TTL is 0 seconds, and the maximum value is 2147483647 seconds. For each entry, the TTL path must be unique for the CDN. If multiple paths match a given content, the most recently configured path match applies to that content. For example, consider two TTLs, /example/file created first with a time to live value of 3000 seconds and /example/* is created later, with a value of 4000 seconds. Although /example/file is more specific, /example/ was created most recently, so the TTL for /example/file is 4000 seconds. After creation, TTL entries can be edited for path, time, or both. TTL entries can also be deleted.





 Token authentication 

Token authentication is the process of generating tokens, associating them with an authenticated user session, and validating the request by using these tokens to prevent unauthorized sharing of links to your content.
To specify mutiple conditions, specify the flag multiple times --conditions "claim:CLAIM1,operator:OPERATOR1,value:VALUE1" --conditions "claim:CLAIM2,operator:OPERATOR2,value:VALUE2".

--expiration
: Specify an expiration in seconds for SAML rules. Must not be provided for trusts established to Compute Resources (type = Profile-CR).

--name
: Name for the rule.

--cr-type
: The compute resource type the rule applies to, required only if type is specified as 'Profile-CR'. Values are VSI for Virtual Service Instance on VPC, IKS_SA for Service Accounts on Kubernetes clusters, or ROKS_SA for managed Red Hat OpenShift.

--realm-name
: Issuer Id for trusts established via IBMid with federation, or appid:// for trusts established via App ID federation. Must not be provided for trusts established to Compute Resources (type = Profile-CR).

--output FORMAT
: Specify output format. Only 'JSON' is supported.

-f, --force
: Force failure if multiple profiles are found.

-q, --quiet
: Suppress verbose output.





 Examples 

Create a Profile-SAML rule with rule name my-rule, realm name set to https://w3id.sso.ibm.com/auth/sps/samlidp2/saml20, expiration set to 1200 seconds for trusted profile my-profile with the rule conditions: cn EQUALS my_user

ibmcloud iam trusted-profile-rule-create my-profile --name my-rule --type Profile-SAML --conditions claim:cn,operator:EQUALS,value:my_user --realm-name https://w3id.sso.ibm.com/auth/sps/samlidp2/saml20 --expiration 1200
* UI
* CLI
* API







 Removing users from an account 

When you remove a user from an account, the user can no longer log in to the console, switch to your account, or access account resources. Removing a user from an account doesn't delete the IBMid for the user.

Only account owners and users with the correct access can remove others. If you use a service ID to authenticate, you can't remove users from the account. The following access is required for removing users from an account:



* An Identity and access management (IAM) policy for the User management account management service with the Administrator role assigned.
* If you have classic infrastructure in your account, a user must have an IAM policy for the User management account management service with the Administrator role assigned and be an ancestor of the user in the classic infrastructure user hierarchy with the Manage user classic infrastructure permission assigned.



As an alternative to removing a user from your account, you can assign them an access policy with a temporary time-based condition. This way, the user can log in to the console and view the account in their account list, but can't access resources in the account before the policy begins or after the policy expires. For more information, see [Creating a temporary time-based condition](https://cloud.ibm.com/docs/account?topic=account-iam-time-based&interface=apiiam-time-based-temp-api).



 Removing a user from an account in the console 

To remove a user from an account, complete the following steps:



1. In the IBM Cloud® console, click Manage > Access (IAM), and select Users.
2. From the row of the user that you want to remove, click the Actions icon ![Actions icon](https://cloud.ibm.com/docs-content/v1/content/4d8c6eec891cff72b666dc24bd3211810c77fb42/icons/action-menu-icon.svg) > Remove user.



Any resources that are created by the user remain in the account, but any IBM Cloud API keys that the user created are removed.
If both of them are provided, --git-token-path and --git-api-url take precedence.

Return values:



* The command lists incident issue URLs found or created according to the result file and subject.
* If no issues are found, or all found issues have either Exempt or Grace period set, the command exits with zero status.
* If any of the issues that are found have no Exempt or Grace Period set, the command exits with a nonzero status.



Running the command:

$ cocoa incident process --type va --subject us.icr.io/service-image --drilldown-url us.icr.io/service-image@sha256:digest path/to/scan-result.json





 cocoa incident process-legacy 

This command creates incident issues in the provided repository for scenarios when a scan file isn't available. Typically, such scenarios would be non-vulnerability related failures like unit-test failure, branch protection failure, acceptance test failure, and image signing failure. These failures would be non-vulnerabilities, yet they would be a deviation from the compliance posture. If issues exist already for incident-subject-tool combinations, the command does not create new ones. By default, high severity rating is set to issues created.

If --set-due-date is set, the command either creates issues, or updates existing issues with due dates. The due dates are calculated from the grace period of the issue, based on the severity.

If --close-resolved-issues flag is set, the command searches for open issues with the same tool, subject and the incident ID as the current run. If there are any issues found, while the --current-status was passed as success, the command closes those issues.

If --read-only is set, the command does not create new issues or amend existing ones. Results are processed, and existing issues are collected for results. The output contains the issue URL list that are supposed to be tracked in issues if the read-only mode is not activated.

Usage:

cocoa incident process-legacy <options>

Options:

--type (Required) Tool type
* Active - The user has access to the [IBM Cloud infrastructure customer portal](https://control.softlayer.com/) and VPN based on permissions set by the account administrator. This status can be manually selected and changed at any time.
* Disabled - The user does not have access to any permissions or subscriptions on the account, including [customer portal](https://control.softlayer.com/) and VPN. If set to disabled by another user on the account, this status can be manually selected and changed at any time.
* VPN Only - The user has access to only VPN connectivity and cannot access the [customer portal](https://control.softlayer.com/). This status can be manually selected or changed at any time.
* Inactive - The user hasn't used the [customer portal](https://control.softlayer.com/) or VPN in the last 60 days (system-generated status).
* cancel_pending - An administrator on the account cancelled this user and the cancellation is being processed. (system-generated status).



* How do I set up SSL VPN?

SSL VPN is a quick-access connection that connects you to our private network directly for non-production use. For detailed instructions about setting up SSL VPN, see [Getting started with SSL VPN](https://cloud.ibm.com/docs/iaas-vpn?topic=iaas-vpn-getting-started).
* Are there open-source alternatives to SSL VPN?

Yes, you can set up [WireGuard](https://www.wireguard.com/) or [OpenVPN](https://openvpn.net/) servers on IBM Cloud, and build your own VPN tunnels from on-premises to IBM Cloud.
* What is the process of installing MotionPro on Windows, Mac, or Linux?



1. Uninstall your current version of MotionPro (if applicable).
2. Restart your system.
3. Download and install the latest version of MotionPro.





Virtual Router Appliance



* What is a VRA?
console.log('runReclamationAction() response:n' + JSON.stringify(res.result, null, 2));
})
.catch(err => {
console.warn(err)
});





 Restoring a resource by using the CLI 

You can restore a resource within 7 days after you delete it.

Not all resources can be restored. You can run the ibmcloud resource reclamations command to check the resources that you can restore.

To restore a resource by using the CLI, run the following command:

ibmcloud resource reclamation-restore ID [--comment COMMENT]

Enter the following command options:



* ID: The ID of the resource reclamation. This is the reclamation ID and not the resource instance ID. (Required)
* --comment: Comments about the action.



The following example shows how to restore a resource with the d9fendfwlw ID:

ibmcloud resource reclamation-restore "d9fendfwlw"

For more information, see the [ibmcloud resource reclamations command reference](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_commands_resourceibmcloud_resource_reclamations).





 Restoring a resource by using the API 

You can restore a resource within 7 days after you delete it.

Not all resources can be restored. [Get a list of all reclaimations](https://cloud.ibm.com/apidocs/resource-controller/resource-controller?code=golist-reclamations) to check the resources that you can restore.

To restore a resource by using the API, call the [IBM Cloud® Resource Controller API](https://cloud.ibm.com/apidocs/resource-controller/resource-controller?code=gorun-reclamation-action) as shown in the following example. Specify restore to restore a resource. id is the reclamation ID and not the resource instance ID.



* Curl
* Java
* Python
* Go
* Node
Attempt to retry the requests in such situations by using the following values:



* Limit = 60 seconds: total time that the service retries.
* Step = 5 seconds: after each failure, the service waits 5 seconds before retrying. This delay prevents bombarding of the external services (webhook).



In addition, the following timeout conditions cause the Cloud Functions call to fail:



* A connection timeout of 10 seconds
* A response timeout of 60 seconds



If a call to the Cloud Functions webhook URL fails even after retry attempts, the notification is lost.
* Origin Cache Control
* Forwarding URL







 Serve Stale Content 

You can use the Serve Stale Content page rule setting to keep a limited version of your site online if your server goes down.

With Serve Stale Content, when your server goes down, CIS serves pages from our cache, so your visitors still see some of the pages they are trying to visit. Your visitors see a message at the top of the page telling them that they are in offline browsing mode. Serve Stale Content returns an HTTP status 503, however, 503 is also used by many other web applications. When your server comes back online, CIS bumps users back to regular browsing seamlessly.

If CIS does not have the requested page in its cache, your visitor sees an error page letting them know that the website page they are requesting is offline.



 Setting up Serve Stale Content 

To enable Serve Stale Content, follow these steps:



1. Use the navigation menu to select Page Rules under Performance.
2. Create a page rule with the URL pattern of your domain.
3. Add the Serve Stale Content setting with the toggle on.
4. Select Provision Resource.







 Serve Stale Content limitations 



* Serve Stale Content caches the first 10 links from your root HTML, then just the first links from each of those pages, and finally the first links from each of those subsequent pages. This means that only some pages on your site are viewable when your origin server goes down.
* Recently added sites don't have a large cache of their site available, which means that Serve Stale Content might not work if you only added the site a few days ago.
* CIS does not show private content or handle form submission (POSTs) if your server is down. Visitors are shown an error on checkout page or items require a login to view.
* To trigger Serve Stale Content, your web server must be returning a standard HTTP Error code of 502 or 504 timeout. Serve Stale Content also works when we encounter issues contacting your origin (Errors 521 & 523), timeouts (522 & 524), SSL errors (525 & 526) or an unknown error (520).
[Create an import token](https://cloud.ibm.com/docs/key-protect?topic=key-protect-create-import-tokens) that you can use to encrypt and import a root key to the Key Protect instance. By default, the import token expires after 10 minutes (600 seconds).

ibmcloud kp import-token create
-i, --instance-id INSTANCE_ID
[-e, --expiration EXPIRATION_TIME_SECONDS]
[-m, --max-retrievals MAX_RETRIEVALS]



 Example 

This example creates a import token. The import token consists of a nonce and a public key.

A nonce is an arbitrary number that can be used just once in a cryptographic communication.

 create an import token that expires in 5 minutes and allows 3 retrievals
$ ibmcloud kp import-token create --expiration 300 --max-retrievals 3

Created Expires Max Retrievals Remaining Retrievals
2020-05-04 19:12:07 +0000 UTC 2020-05-04 19:17:07 +0000 UTC 3 3

 show the created token
$ ibmcloud kp import-token show

{
"nonce": "8rf2ldP/zWm1Tjrb",
"payload":
"LS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0t ...<redacted>... QyBLRVktLS0tLQo="
}





 Required parameters 



* -i, --instance-id

The IBM Cloud instance ID that identifies your Key Protect instance.

You can set an environment variable instead of specifying -i with the following command: $ export KP_INSTANCE_ID=<INSTANCE_ID>.







 Optional parameters 



* -e, --expiration

Specify an expiration time (in seconds) for an import token. This value determines how long the import token and its associated public key remain valid for operations.
You can determine whether to remove the inactive policies, or in some cases, you might expect an infrequently used policy. For more information, see [Managing inactive policies](https://cloud.ibm.com/docs/account?topic=account-iam-audit-policies&interface=uiiam-audit-policies-list).

Exporting user access reports
: Make sure that users have only the access that they need. Export an access policy report for any user in your account to view all of the access policies that they are assigned. For more information, see [Exporting user access policy reports](https://cloud.ibm.com/docs/account?topic=account-iam-audit-policies&interface=uiaudit-user-access).





 22 September 2022 

A new way to provide IBM Cloud your feedback
: We want to hear from you! Let us know about your experience with the IBM Cloud console by submitting your feedback from the Help > Send feedback option in the console menu bar. You can tell us what you love and even what you’d like to see improved, so we can work together to ensure that you always enjoy developing on IBM Cloud.





 21 September 2022 

Getting help in the console
: You can now find the documentation and Support Center help options from a single menu item in the IBM Cloud console menu bar. Check out the new Help option from the console menu bar that now includes your links for [Docs](https://cloud.ibm.com/docs), the [Support Center](https://cloud.ibm.com/unifiedsupport/supportcenter), a form to give us feedback, and available guided tours.





 16 September 2022 

Attaching tags on service IDs
: In addition to tagging resources, you can now attach user tags and access management tags on service IDs. User tags help you group service IDs for usage reports, and you can use access management tags to control access to your service IDs. For more information, see [Working with tags](https://cloud.ibm.com/docs/account?topic=account-tag&interface=ui).

Specifying a user onboarding strategy
ID String None Rule Must consist of (a-z,A-Z0-9) and the following symbols:!_.*'()- 
 Filter String Prefix Rule Must contain a Prefix element 
 Prefix String None Filter The rule applies to any objects with keys that match this prefix. 
 Expiration Container Days or Date Rule Limit 1. 
 Days Non-negative integer None Expiration Must be a value greater than 0. 
 Date Date None Expiration Must be in ISO 8601 Format. 



Syntax

PUT https://{endpoint}/{bucket}?lifecycle path style
PUT https://{bucket}.{endpoint}?lifecycle virtual host style

Example request

PUT /images?lifecycle HTTP/1.1
Host: s3.us.cloud-object-storage.appdomain.cloud
Date: Wed, 7 Feb 2018 17:50:00 GMT
Authorization: authorization string
Content-Type: text/plain
Content-MD5: M625BaNwd/OytcM7O5gIaQ==
Content-Length: 305

<LifecycleConfiguration>
<Rule>
<ID>id1</ID>
<Filter />
<Status>Enabled</Status>
<Expiration>
<Days>60</Days>
</Expiration>
</Rule>
</LifecycleConfiguration>
Show more

--------------------





 Delete the lifecycle configuration for a bucket 

A DELETE issued to a bucket with the proper parameters removes any lifecycle configurations for a bucket.

Syntax

DELETE https://{endpoint}/{bucket-name}?lifecycle path style
DELETE https://{bucket-name}.{endpoint}?lifecycle virtual host style

Example request

DELETE /apiary?lifecycle HTTP/1.1
Authorization: {authorization-string}
Host: s3.us.cloud-object-storage.appdomain.cloud

Example request