vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Using trusted profiles to authorize a project to deploy an architecture 

Some services cannot fully configure and deploy architectures by using trusted profiles. In the future, projects can be directly authorized by using a trusted profile. For now, [use an API key or secret to authorize a project to deploy an architecture](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-authorize-project). For more information, see [Known issues and limitations for projects](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-known-issuesauth-known-issue).

When you configure your deployable architecture, you are required to select an authentication method. A project can assume a [trusted profile](https://cloud.ibm.com/docs/account?topic=account-create-trusted-profile), which grants the project access to deploy an architecture in the account where the trusted profile exists. This way, you can securely deploy an architecture without the need for key rotation.

The project uses the trusted profile to create a service ID with the same permissions as the trusted profile and a fresh API key for that service ID to authorize each deployment. Because the temporary API key exists only for the lifetime of the operation, this improves security because it's harder to misuse. The trusted profile needs access to create a service ID and create and delete API keys for the service ID, as well as access to deploy the deployable architecture.



 Deploying an architecture in your account or another account 

You can deploy an architecture in your own account or in another account by using trusted profiles.

Depending on your organization, deploying an architecture might require access to another account by using a trusted profile and coordinating with administrators in multiple accounts. If the IBM Cloud Projects service in another account needs access to your account to deploy an architecture, use trusted profiles and service IDs to authorize deployments in your account.





 Before you begin 

Make sure that you create the trusted profile in the account where you want to deploy the architecture. If you have the following access, you can create trusted profiles:



* Account owner
* Administrator role on all account management services
Configuring pod security policies 

With [pod security policies (PSPs)](https://kubernetes.io/docs/concepts/security/pod-security-policy/), you can configure policies to authorize who can create and update pods in IBM Cloud® Kubernetes Service.

Pod security policies are not available in clusters that run version 1.25 or later. In clusters that run version 1.25 or later, use [Pod Security admission](https://cloud.ibm.com/docs/containers?topic=containers-pod-security-admission) instead. To upgrade a cluster with pod security policies from version 1.24 to version 1.25, follow the steps in [Migrating from PSPs to Pod Security Admission](https://cloud.ibm.com/docs/containers?topic=containers-pod-security-admission-migration).



 FAQs 

Learn about some common FAQs for configuring your pod security policies.



 Why do I set pod security policies? 

As a cluster admin, you want to control what happens in your cluster, especially actions that affect the cluster's security or readiness. Pod security policies can help you control usage of privileged containers, root privileges, host networking and ports, volume types, host file systems, Linux capabilities, and more.

With the PodSecurityPolicy admission controller, pod creation is controlled by pod security policies and related role-based access control (RBAC). By default, IBM Cloud Kubernetes Service clusters don't restrict pod creation for any authenticated users or service accounts. To secure your cluster, customize the pod security policies. This customization can have unintended side-effects, so make sure to thoroughly test your customizations. To deploy apps, the user and service accounts must all be authorized by the pod security policies that are required to deploy pods.

Trying to control which users have access to the IBM Cloud Kubernetes Service? See [Assigning cluster access](https://cloud.ibm.com/docs/containers?topic=containers-usersusers) to set IBM Cloud IAM and infrastructure permissions.





 Are any policies set by default? What can I add?
You can use IBM Cloud key management with VMware vSphere or vSAN encryption. For more information, see the [KMIP for VMware implementation guide](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-kmip-implementation).





 Working with customer-managed keys for VMware Solutions 

For more information about considerations for VMware key management, key revocation, and key rotation, see:



* [KMIP for VMware considerations](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-kmip-designkmip-design-considerations)
* [KMIP for VMware management guide](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-kmip-implementationkmip-implementation-key-rotation)









 Deleting your data in VMware Solutions 



 Deleting VMware Solutions instances 

When a customer deletes a vCenter Server instance, all associated customer workload data is deleted. The underneath IaaS resources are also deleted at the end of the corresponding billing cycle.

When a customer deletes a VMware Shared instance, all associated customer data is deleted immediately.

Along with the instance deletion, the instance's configuration and metadata are also marked as "inactive". You can request complete deletion of the metadata through a "secure wipe" ticket.





 Restoring deleted data for VMware Solutions 

You are responsible to make provision for backup and recovery of all data you bring to VMware Solutions. IBM Cloud does not back up your workload data and cannot restore it after deletion.







 Related links 



* [Managing IAM access for VMware Solutions](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-iam)
* [Auditing events for VMware Solutions](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-at-events)
After verification, you can invite individual users or users in IBM Cloud IAM access groups to that region by setting platform access policies for them in that region. A user with a Viewer platform access role isn't authorized to add a worker node. Therefore, the worker-add action fails, even though the API key has the correct infrastructure permissions. If you change the user's platform access role to Operator, the user is authorized to add a worker node. The worker-add action succeeds because the user is authorized and the API key is set correctly. You don't need to edit the user's IBM Cloud infrastructure permissions.

To audit the actions that users in your account run, you can use [Activity Tracker](https://cloud.ibm.com/docs/openshift?topic=openshift-at_events) to view all cluster-related events.





 What if I don't want to assign the API key owner or credentials owner the Super User infrastructure role? 

For compliance, security, or billing reasons, you might not want to give the Super User infrastructure role to the user who sets the API key or whose credentials are set with the ibmcloud oc credential set command. However, if this user doesn't have the Super User role, then infrastructure-related actions, such as creating a cluster or reloading a worker node, can fail. Instead of using IBM Cloud IAM platform access roles to control users' infrastructure access, you must [set specific IBM Cloud infrastructure permissions](https://cloud.ibm.com/docs/openshift?topic=openshift-access-credsinfra_access) for users.





 What happens if the user who set up the API key for a region and resource group leaves the company? 

If the user is leaving your organization, the IBM Cloud account owner can remove that user's permissions. However, before you remove a user's specific access permissions or remove a user from your account completely, you must reset the API key with another user's infrastructure credentials. Otherwise, the other users in the account might lose access to the IBM Cloud infrastructure portal and infrastructure-related commands might fail.
Troubleshooting known issues 

Get help with solving issues that you might encounter while using Watson Assistant.



 4.5.x 



 Pod "RESTARTS" count stays at 0 after a 4.5.x upgrade even though a few assistant pods are restarting 



* Problem: After upgrading Watson Assistant, the pod "RESTARTS" count stays at 0 even though certain assistant pods are restarting.
* Cause: During the upgrade, custom resources owned by Watson Assistant for the "certificates.certmanager.k8s.io" CRD are deleted using a script that runs in the background. Sometimes the CR deletion script completes before the assistant operator gets upgraded. In that case, the old assistant operator might recreate custom resources for the "certificates.certmanager.k8s.io" CRD. Leftover CRs might cause the certificate manager to continuously regenerate some certificate secrets, causing some assistant pods to restart recursively.
* Solution: Run the following script to delete leftover custom resources for the "certificates.certmanager.k8s.io" CRD after setting INSTANCE (normally wa) and PROJECT_CPD_INSTANCE variables:



for i in oc get certificates.certmanager.k8s.io -l icpdsupport/addOnId=assistant --namespace ${PROJECT_CPD_INSTANCE} | grep "${INSTANCE}-"| awk '{print $1}'; do oc delete certificates.certmanager.k8s.io $i --namespace ${PROJECT_CPD_INSTANCE}; done







 4.5.0 



 Data Governor not healthy after installation 

After Watson Assistant is installed, the dataexhausttenant custom resource named wa-data-governor-ibm-data-governor-data-exhaust-internal gets stuck in the Topics phase. When this happens, errors in the Data Governor pods report that the service does not exist.



1. Get the status of the wa-data-governor custom resource:

oc get DataExhaust
2. Wait for the wa-data-governor custom resource to be in the Completed phase:

NAME STATUS VERSION COMPLETED
wa-data-governor Completed master 1s
3.
The following actions apply if an unexpected host failure occurs:



* The virtual servers that were running on the host are stopped when the outage is detected.
* The virtual servers are automatically reassigned and restarted on a different compute host in the same multi-region zone.
* The virtual servers that are restarted use the same boot volume, and the same data volumes as the original virtual server.
* The virtual server that was restarted is assigned the same floating IP, static IP, and dynamic IP addresses on the new node.
* If the virtual server cannot be scheduled to run on another compute node, it is placed in a FAILED state.





* Can I use an encrypted image?

Yes, you can encrypt a supported custom image with LUKS encryption and your own passphrase. For more information, see [Creating an encrypted custom image](https://cloud.ibm.com/docs/vpc?topic=vpc-create-encrypted-custom-image). When your image is encrypted and imported to IBM Cloud VPC, you can use it to provision virtual server instances.
* Can I use my own license for a custom image that I create?

Yes, for certain versions of Red Hat Enterprise Linux (RHEL) and Windows operating systems, you can bring your own license (BYOL) to the IBM Cloud VPC when you import a custom image. These images are registered and licensed by you. You maintain control over your license and incur no additional costs by using your license. For more information, see [Bring your own license](https://cloud.ibm.com/docs/vpc?topic=vpc-byol-vpc-about).
* How does IBM handle maintenance?

For more information, see [Understanding Cloud Maintenance Operations](https://cloud.ibm.com/docs/vpc?topic=vpc-about-cloud-maintenance).
* What happens if my virtual server host fails?

For more information, see [Understanding Cloud Maintenance Operations](https://cloud.ibm.com/docs/vpc?topic=vpc-about-cloud-maintenance).
Select a Target service as per your requirement (Key Protect or Hyper Protect Crypto Services).
7. For the target service, specify whether you want the authorization to be for all instances, only to a specific instance in the account, or instances only in a certain resource group.
8. Select a role to assign access to the source service that accesses the target service.
9. Click Authorize.







 Creating an authorization by using the CLI 

To authorize a source service access a target service, run the ibmcloud iam authorization-policy-create command.

For more information about all of the parameters that are available for this command, see [ibmcloud iam authorization-policy-create](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_commands_iamibmcloud_iam_authorization_policy_create).
[Check mark icon](https://cloud.ibm.com/docs-content/v1/content/0bc8db34a3d90b2a5103c9c71b08a96de9525bbc/icons/checkmark-icon.svg) 
 Enable a key ![Check mark icon](https://cloud.ibm.com/docs-content/v1/content/0bc8db34a3d90b2a5103c9c71b08a96de9525bbc/icons/checkmark-icon.svg) 
 Schedule deletion for a key ![Check mark icon](https://cloud.ibm.com/docs-content/v1/content/0bc8db34a3d90b2a5103c9c71b08a96de9525bbc/icons/checkmark-icon.svg) ![Check mark icon](https://cloud.ibm.com/docs-content/v1/content/0bc8db34a3d90b2a5103c9c71b08a96de9525bbc/icons/checkmark-icon.svg) 
 Cancel deletion for a key ![Check mark icon](https://cloud.ibm.com/docs-content/v1/content/0bc8db34a3d90b2a5103c9c71b08a96de9525bbc/icons/checkmark-icon.svg) ![Check mark icon](https://cloud.ibm.com/docs-content/v1/content/0bc8db34a3d90b2a5103c9c71b08a96de9525bbc/icons/checkmark-icon.svg) 
 Delete a key !
8. In the Target service instance menu, select the service instance to authorize. The additional fields may be left blank.
9. Enable the Reader role.
10. Click Authorize.







 Create a bucket 

When your key exists in Key Protect and you authorized the service for use with IBM COS, associate the key with a new bucket:



1. Navigate to your instance of Object Storage.
2. Click Create bucket.
3. Select Custom bucket.
4. Enter a bucket name, select the Regional resiliency, and choose a location and storage class.
5. In Service integrations, toggle Key management disabled to enable encryption key management and click on Use existing instance.
6. Select the associated service instance and key, and click Associate key.
7. Verify the information is correct.
8. Click Create.



You can choose to use Key Protect to manage encryption for a bucket only at the time of creation. It isn't possible to change an existing bucket to use Key Protect.

If bucket creation fails with a 400 Bad Request error with the message The Key CRN could not be found, ensure that the CRN is correct and that the service to service authorization policy exists.

In the Buckets listing, the bucket has a View link under Attributes where you can verify that the bucket has a Key Protect key enabled.

Note that the Etag value returned for objects encrypted using SSE-KP will be the actual MD5 hash of the original decrypted object.
Refresh tokens 

App ID supports the ability to acquire new access and identity tokens without reauthentication, as defined in [OIDC](https://openid.net/specs/openid-connect-core-1_0.htmlRefreshTokens). A refresh token can be used to renew the access token so a user doesn't have to take any action to sign in, such as providing credentials. Similar to access tokens, refresh tokens contain data that allow App ID to determine whether you authorized. However, these tokens are opaque.

Refresh tokens are configured to have a longer life span than a regular access token. When an access token expires, the refresh token is still valid and can be used to renew the access token. App ID’s refresh tokens can be configured to last 1 - 90 days. To take full advantage of refresh tokens, persist the tokens for their full life span, or until they are renewed. A user cannot directly access resources with just a refresh token, which makes them much safer to persist than an access token. As best practice, refresh tokens should be securely stored by the client that received them and sent only to the authorization server that issued them.

For added convenience, App ID also renews its refresh token — and its expiration date — when the access token is renewed, allowing the user to remain logged in while they are active at some point before the current refresh token expires. Alternatively, if you would like to use refresh tokens yet force the user to log in periodically, your app might use only the refresh tokens that are returned when the user logs in by entering their credentials. However, we recommend always using the latest refresh token that is received from App ID, as described by the [OAuth 2.0 specifications](https://datatracker.ietf.org/doc/html/rfc6749.).

Although these tokens can streamline the login process, your app must not depend on them. They can be revoked at any time, such as when you believe that your refresh tokens were compromised.
The CPU utilization can be affected by the total workload of the hosting hardware and other factors.
* Responsetime is the average amount of time that the app takes to respond to a request. Responsetime is specified in ms (milliseconds).
* Throughput is the total number of the requests that are processed in a time period. Throughput is specified in rps (requests per second).
* Custom_metric is your own custom metric. The Custom_metric name can be any alphanumeric value. Autoscaling is triggered when the corresponding metric is emitted to the App Autoscaler. For more information, see the [custom metric usage guide](https://github.com/cloudfoundry/app-autoscaler/tree/develop/docsauto-scale-your-application-with-custom-metrics).



In addition to specifying the metric type, specify an operator, threshold, breach duration, adjustment, and cooldown period values.

When the threshold is continuously breached during the breach duration period, and beyond the cooldown period, the App AutoScaler triggers the defined autoscaling action. The number or percentage of app instances is adjusted.



* The operator can be >=, >, <=, or <.
* The threshold must be a numeric value.
* The breach duration is defined in seconds. The default value is 120 seconds.
* The adjustment value specifies how the number of app instances change in each scaling action. You can specify an absolute number or a percentage of instances to add or remove.
* The cooldown period specifies the time to wait before the taking the next autoscaling action. A cooldown period ensures that your app does not launch new instances or stop existing instances before your app is stable. The cooldown period is specified in seconds. The default cooldown period is 300 seconds.



4. (Optional) Define Schedules to scale your app during a set time period.

You can define specific time periods when you know that your app requires different numbers of instances to handle peak loads. The schedule policy overwrites the default instance limits and sets the number of instances to the Initial Minimum Instance Count value for the scheduled period.
Viewing bandwidth graphs 

Public data network traffic that is transferred Outbound from IBM Cloud® data centers around the globe are assessed as outbound bandwidth charges. Bandwidth graphs display public and private network usage for all network traffic that is associated with your device for a time period.



  Before you begin 



*  Go to your console's device menu. For more information, see [Navigating to devices](https://cloud.ibm.com/docs/bare-metal?topic=virtual-servers-navigating-devices).
*  Make sure that you have any necessary account permissions and device access. Only the account owner, or a user with the Manage Users classic infrastructure permission, can adjust the permissions.



For more information about permissions, see [Managing device access](https://cloud.ibm.com/docs/vsi?topic=virtual-servers-managing-device-access).





  Viewing your bandwidth graphs 

To view your bandwidth graphs, follow these steps:



1.  Click the Menu icon ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/icons/icon_hamburger.svg) > Classic Infrastructure > Network > Bandwidth.
2.  Select the type of network usage (public or private) from the View list.
3.  Select the time period for the graph from the View By drop-down list. Preset date ranges are most commonly queried. For a custom date range, select Custom Date Range.
4.  Select the start and end dates from the corresponding drop-down calendars.
5.  Click Draw Graph.







  Optimizing your bandwidth usage 

You can optimize bandwidth usage by "pooling" all of the bandwidth together for servers into a bandwidth pool. Bandwidth averages for servers in a bandwidth pool are summed up as a whole. Averages are calculated only if the total bandwidth of all servers exceeds the total allocated bandwidth for all servers versus metering at the individual server level.





  Adding a bandwidth pool 

To add a bandwidth pool, click Network > Bandwidth > Pools > Add.





  What happens next 

The graph appears under the selected details and displays the requested data for the time range in bits per second (bps).
Vyatta 5400 end of support FAQs 

These frequently asked questions can help you when migrating from the Vyatta 5400 to the IBM Cloud® Virtual Router Appliance.



 Why is the Vyatta 5400’s “End of Support” (EoS) on March 31, 2019? 

In September 2017, the legacy Vyatta 5400 announced its EoS to be on February 20, 2018. Based on IBM’s lifecycle policy for support, EoS was six months after the General Availability (GA) date of IBM Cloud® Virtual Router Appliance (VRA).

To honor customer migration timelines, the Vyatta 5400 EoS date was extended to March 31, 2019. Because the Debian 7 software is now no longer supported by the Debian Open Source community, there are no future plans to extend vendor support from AT&T.

For more information, see the [End of Support Announcement](https://cloud.ibm.com/docs/virtual-router-appliance?topic=virtual-router-appliance-vyatta-5400-end-of-support-announcement).





 What does “End of Support” mean for me as a customer? 

After the End of Support date, AT&T no longer provides any code patches or accept support escalations from IBM.

Similarly, IBM Cloud Support no longer troubleshoots configuration or networking issues on Vyatta 5400 deployments. Support is limited to hardware level requests (hard drive, RAM, and so on), power and Out of Band (IPMI) connectivity.

It is highly recommend that customers take immediate action to migrate onto an alternate solution, such as the IBM Cloud® Virtual Router Appliance (VRA; based on the Vyatta 5600) or Juniper vSRX. See [Migrating Vyatta 5400](https://cloud.ibm.com/docs/virtual-router-appliance?topic=virtual-router-appliance-migration-overview) to get started.





 What happens if I'm still running my IBM Cloud workloads using a Vyatta 5400 after March 31? 

Your Vyatta 5400 continues to work after March 31.
Click the Calendar icon below the text field "Requested Start" and select the date and time you would like the job to start.

![SSP-Start-Time](https://cloud.ibm.com/docs-content/v1/content/bd177462727ef0a849ddcf8c842a6203b41f0625/mas-ms/images/SSP-SR-Start-Time.png)
4. Select the environment to run the action against by clicking on the magnifying glass next to the "Target Environment" field. Select the environment from the pop-up list.

![SSP-Select-Asset](https://cloud.ibm.com/docs-content/v1/content/bd177462727ef0a849ddcf8c842a6203b41f0625/mas-ms/images/SSP-Select-Asset.png)
5. Select the action you would like to take by clicking on the magnifying glass next to the "Requested Action" field. Select the action from the pop-up list. Fill in any required information for the chosen action.

If you select a production asset then the pop-up list will be empty.

![SSP-Select-Action](https://cloud.ibm.com/docs-content/v1/content/bd177462727ef0a849ddcf8c842a6203b41f0625/mas-ms/images/SSP-Select-Action.png)
6. Click Save. And then Click the Queue Request button.

If the request is not queued it will remain in new state and will not be run.

![SSP-Queue-Request](https://cloud.ibm.com/docs-content/v1/content/bd177462727ef0a849ddcf8c842a6203b41f0625/mas-ms/images/SSP-Queue-Request.png)
7.