vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Why do my pods fail to deploy after applying a pod security policy? 

Virtual Private Cloud

Classic infrastructure

  What’s happening 

After creating a pod or running kubectl get events to check on a pod deployment, you see an error message similar to the following.

unable to validate against any pod security policy

  Why it’s happening 

[The PodSecurityPolicy admission controller](https://cloud.ibm.com/docs/containers?topic=containers-psp) checks the authorization of the user or service account that tried to create the pod.

If no pod security policy supports the user or service account, then the PodSecurityPolicy admission controller prevents the pods from being created.

If you deleted one of the pod security policy resources for [IBM cluster management](https://cloud.ibm.com/docs/containers?topic=containers-pspibm_psp), you might experience similar issues.

  How to fix it 

Make sure that the user or service account is authorized by a pod security policy. You might need to [modify an existing policy](https://cloud.ibm.com/docs/containers?topic=containers-pspcustomize_psp).

If you deleted an IBM cluster management resource, refresh the Kubernetes master to restore it.



1.  [Log in to your account. If applicable, target the appropriate resource group. Set the context for your cluster.](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster)
2.  Refresh the Kubernetes master to restore it.

ibmcloud ks cluster master refresh
The information and steps are also documented in Upgrading Watson Speech services from Version 4.0 to Version 4.5 in the Upgrading topic of [Watson Speech services on IBM Cloud Pak for Data](https://www.ibm.com/docs/en/cloud-paks/cp-data/4.5.x?topic=services-watson-speech).



1. Use the following command to identify pods that remain in the Terminating state:



oc get pods -n ${PROJECT_CPD_INSTANCE} -o wide | awk {'print $1'}



1. Use the following command to set the environment variable pods to include the list of pods that remain in the Terminating state:



pods=$(oc get pods -n ${PROJECT_CPD_INSTANCE} -o wide | grep Terminating | awk {'print $1'})



1. Use the following command to delete the stuck pods so that the upgrade process can continue:



oc delete pod $pods -n ${PROJECT_CPD_INSTANCE} --force=true --grace-period=0

Documentation updates for the SSML <prosody> element
: The documentation for the SSML <prosody> element and its pitch and rate parameters has been improved and clarified. It also now includes a description of the differences between the service and the latest version of the SSML specification. For more information, see [The <prosody> element](https://cloud.ibm.com/docs/text-to-speech?topic=text-to-speech-elementsprosody_element).

Security vulnerabilities addressed
: The following security vulnerabilities have been fixed:



* [Security Bulletin: IBM Watson Speech Services Cartridge for IBM Cloud Pak for Data is vulnerable to a buffer over-read flaw in Linux Kernel (CVE-2020-28915)](https://www.ibm.com/support/pages/node/6829133)
If restarting your pod does not resolve the issue, [reload your worker nodes](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_worker_reload).
3. Verify that you use the latest IBM Cloud and IBM Cloud Kubernetes Service plug-in version.

ibmcloud update

ibmcloud plugin repo-plugins

ibmcloud plugin update







 Verifying that the storage driver and plug-in pods show a status of Running 

Follow the steps to check the status of your storage driver and plug-in pods and review any error messages.



1. List the pods in the kube-system project.

oc get pods -n kube-system
2. If the storage driver and plug-in pods don't show a Running status, get more details of the pod to find the root cause. Depending on the status of your pod, the following commands might fail.



1. Get the names of the containers that run in the driver pod.

kubectl describe pod <pod_name> -n kube-system
2. Export the logs from the driver pod to a logs.txt file on your local machine.

oc logs <pod_name> -n kube-system > logs.txt
3. Review the log file.

cat logs.txt



3. Check the latest logs for any error messages. [Review the Object Storage troubleshooting documentation for steps to resolve common errors](https://cloud.ibm.com/docs/openshift?topic=openshift-sitemapsitemap_object_storage).







 Checking whether your PVC is successfully provisioned 

Follow the steps to check the status of your PVC and review any error messages.



1. Check the status of your PVC. A PVC is successfully provisioned if the PVC shows a status of Bound.

oc get pvc



* If the PVC shows a status of Bound, the PVC is successfully provisioned.

Example output

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
appconfig_client.set_context(collection_id='airlines-webapp', environment_id='dev')

 2. optional (with persistent cache)
appconfig_client.set_context(collection_id='airlines-webapp', environment_id='dev', options={
'persistent_cache_dir': '/var/lib/docker/volumes/'
})

Where:



* persistent_cache_dir: Absolute path to a directory that has read and write permission for the user. The SDK creates a file - appconfiguration.json in the specified directory, and it is used as the persistent cache to store the App Configuration service information.

When persistent cache is enabled, the SDK keeps the last known good configuration at the persistent cache. If the App Configuration server is unreachable, the latest configurations at the persistent cache are loaded to the application to continue working.



Ensure that the cache file created in the given directory is not lost or deleted in any case. For example, consider the case when a kubernetes pod is restarted and the cache file (appconfiguration.json) was stored in ephemeral volume of the pod. As pod gets restarted, kubernetes destroys the ephermal volume in the pod, as a result the cache file gets deleted. So, make sure that the cache file created by the SDK is always stored in persistent volume by providing the correct absolute path of the persistent directory.





 Offline options 

The SDK is also designed to serve configurations, and perform feature flag and property evaluations without being connected to App Configuration service.

appconfig_client.set_context(collection_id='collection_id', environment_id='environment_id', options={
'bootstrap_file': 'saflights/flights.json',
'live_config_update_enabled': False
})

Where:



* bootstrap_file: Absolute path of the JSON file, which contains configuration details. Make sure to provide a proper JSON file.
Location message
: Pods have been stuck in a terminating state on the location control plane node for over an hour.

Steps to resolve
: Pods that remain in a terminating state for an hour or more indicate that the location control plane is not healthy. Follow the steps to replace the location control plane hosts.

When you update or replace control plane hosts, do not assign or remove multiple hosts at the same time as doing so may break the control plane. You must wait for a host assignment or removal to complete before assigning or removing another host. \n To avoid possible service disruptions, make sure you attach and assign additional hosts to the control plane before removing any hosts.



1. For each host you want to remove from the control plane, [attach an additional host](https://cloud.ibm.com/docs/satellite?topic=satellite-attach-hosts).
2. [Assign the attached hosts](https://cloud.ibm.com/docs/satellite?topic=satellite-attach-hosts) to your location. Make sure that you only assign hosts one at a time and that each assignment completes before you assign another host.
3. [Remove the original hosts from your Satellite location](https://cloud.ibm.com/docs/satellite?topic=satellite-host-remove). Make sure that you only remove hosts one at a time and that each removal completes before you remove another host.



For additional information about the affected components, [set up Log Analysis](https://cloud.ibm.com/docs/satellite?topic=satellite-get-helpreview-logs) and review the [R0056 error logs](https://cloud.ibm.com/docs/satellite?topic=satellite-healthlogs-error).





 R0057: Outbound traffic to IAM is failing 

Location message
: Outbound traffic to IBM Cloud IAM is failing. To ensure that all host requirements are met, see [Host system requirements](https://cloud.ibm.com/docs/satellite?topic=satellite-host-reqs). More information is available in the IBM Cloud Platform Logs.
[Debugging Portworx failures](https://cloud.ibm.com/docs/openshift?topic=openshift-debug_storage_pxdebug_storage_px)



* [Checking whether the pod that mounts your storage instance is successfully deployed](https://cloud.ibm.com/docs/openshift?topic=openshift-debug_storage_pxdebug_storage_px_deploy)
* [Restarting your app pod](https://cloud.ibm.com/docs/openshift?topic=openshift-debug_storage_pxdebug_storage_px_restart)
* [Verifying that the Portworx storage driver and plug-in pods show a status of Running](https://cloud.ibm.com/docs/openshift?topic=openshift-debug_storage_pxdebug_storage_px_driver_plugin)
* [Checking and updating the oc CLI version](https://cloud.ibm.com/docs/openshift?topic=openshift-debug_storage_pxdebug_storage_px_cli)
* [Updating Helm charts](https://cloud.ibm.com/docs/openshift?topic=openshift-debug_storage_pxdebug_storage_px_helm)



[Debugging your Portworx installation](https://cloud.ibm.com/docs/openshift?topic=openshift-debug-portworxdebug-portworx)



* [Step 1: Verifying the IBM Cloud catalog information](https://cloud.ibm.com/docs/openshift?topic=openshift-debug-portworxpx-verify-catalog)
* [Step 2: Verifying the cluster setup](https://cloud.ibm.com/docs/openshift?topic=openshift-debug-portworxpx-verify-cluster)
Listing installed plug-ins...

Plugin Name Version Status Private endpoints supported
container-registry 0.1.556 true
container-service[kubernetes-service] 1.0.353 false
cra 0.1.11 false
doi 0.3.3 false
schematics 1.7.0 false
cloud-functions[wsk/functions/fn] 1.0.58 false
cloud-internet-services 1.14.0 true
code-engine[ce] 1.24.0 true

 ibmcloud dev --version
ibmcloud dev version 2.10.0

 java -version
openjdk version "11.0.11" 2021-04-20
OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
Eclipse OpenJ9 VM AdoptOpenJDK-11.0.11+9 (build openj9-0.26.0, JRE 11 Linux amd64-64-Bit Compressed References 20210421_975 (JIT enabled, AOT enabled)
OpenJ9 - b4cc246d9
OMR - 162e6f729
JCL - 7796c80419 based on jdk-11.0.11+9)

 ant -version
Apache Ant(TM) version 1.10.12 compiled on October 13 2021

 mvn -version
Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /opt/IBM/maven
Java version: 11.0.11, vendor: AdoptOpenJDK, runtime: /usr/local/openjdk-11
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.10.76-linuxkit", arch: "amd64", family: "unix"

 gradle -version

Welcome to Gradle 7.3.3!
Listing installed plug-ins...

Plugin Name Version Status Private endpoints supported
cloud-internet-services 1.13.6 true
code-engine[ce] 1.23.1 true
container-registry 0.1.553 true
container-service[kubernetes-service] 1.0.344 false
cra 0.1.9 false
doi 0.3.3 false
schematics 1.6.1 false
cloud-functions[wsk/functions/fn] 1.0.56 false

 ibmcloud dev --version
ibmcloud dev version 2.9.1

 java -version
openjdk version "11.0.11" 2021-04-20
OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
Eclipse OpenJ9 VM AdoptOpenJDK-11.0.11+9 (build openj9-0.26.0, JRE 11 Linux amd64-64-Bit Compressed References 20210421_975 (JIT enabled, AOT enabled)
OpenJ9 - b4cc246d9
OMR - 162e6f729
JCL - 7796c80419 based on jdk-11.0.11+9)

 ant -version
Apache Ant(TM) version 1.10.12 compiled on October 13 2021

 mvn -version
Apache Maven 3.8.3 (ff8e977a158738155dc465c6a97ffaf31982d739)
Maven home: /opt/IBM/maven
Java version: 11.0.11, vendor: AdoptOpenJDK, runtime: /usr/local/openjdk-11
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.10.47-linuxkit", arch: "amd64", family: "unix"

 gradle -version

Welcome to Gradle 7.2!
"https://github.ibm.com/cocoa-test/e2e-compliance-incident-issues-20220412084808401/issues/3",
],
"attachments": [
{
"hash": "9a841ef856a5de813dbe440b102b9bff3ca1831630292cff7323c557704f386b",
"url": "https://s3.private.us-south.cloud-object-storage.appdomain.cloud/test/assets/9a841ef856a5de813dbe440b102b9bff3ca1831630292cff7323c557704f386b/index.json"
}
]
}
Show more









 v2 evidence summary 

The DevSecOps pipeline creates an evidence summary document. This document contains the most recent of all evidence that is created during each of the continuous integration builds that deploy an image, and the evidence that is created during the deployment itself. The summary is created for the change request that is required to deploy any stage. This format of evidence is not yet supported by the Security and Compliance Center integration.

interface Summary {
version: '2.0'; // schema version
date: string; // ISO-8601, UTC, ie. YYYY-MM-DDThh:mm:ssZ
toolchain_crn: string; // CRN of the toolchain that generated the summary
pipeline_id: string; // ID of the pipeline that generated the summary
pipeline_run_id: string; // ID of the pipeline run that generated the summary
evidences: Evidence[];
}

This summary does not perform any result aggregation. It is the raw data of collected v2 evidence, as they were found for assets that are related to a change request.







 v1 evidence (older format) 



 v1 evidence locker 

Evidence and related artifacts, such as logs and test results are stored in evidence lockers.
How to resolve issues with respect to Keystore enrollment? 

If you get error messages or warnings during the Keystore enrolment, check for the following troubleshooting tips:



1.  Permissions are insufficient: Ensure the user credentials which is connect to the configured Keystore have adequate permissions.
When your app must be rescheduled, Portworx moves your app to a worker node where one of your volume replicas resides to ensure local-disk access speed and best performance for your stateful app. Running hyper-converged offers the best performance for your pods, but requires storage to be available on all worker nodes in your cluster.

You can also choose to use only a subset of worker nodes for your Portworx storage layer. For example, you might have a worker pool with SDS worker nodes that come with local raw block storage, and another worker pool with virtual worker nodes that don't come with local storage. When you install Portworx, a Portworx pod is scheduled onto every worker node in your cluster as part of a DaemonSet. Because your SDS worker nodes have local storage, these worker nodes are into the Portworx storage layer only. Your virtual worker nodes are not included as a storage node because of the missing local storage. However, when you deploy an app pod to your virtual worker node, this pod can still access data that is physically stored on an SDS worker node by using the Portworx DaemonSet pod. This setup is referred to as storage-heavy and offers slightly slower performance than the hyper-converged setup because the virtual worker node must talk to the SDS worker node over the private network to access the data.

IBM Cloud Kubernetes Service does not support the [Portworx experimental InitializerConfiguration admission controller](https://docs.portworx.com/portworx-install-with-kubernetes/storage-operations/hyperconvergence/initializer-experimental-feature-in-stork-v1-1).





 Can I install Portworx in a private cluster? 

Yes. If you want to install Portworx in a private cluster, your IBM Cloud account must be set up with [Virtual Routing and Forwarding (VRF)](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointvrf) and access to private cloud service endpoints for IBM Cloud services.
5. Wait a few minutes then check the Istio operator pod logs for a reconcile loop error. If there is no reconcile loop error, add the next section of the IOP resource configuration to the test file, reapply the file, and check the logs again. Continue checking each section of the IOP resource configuration until you see the reconcile loop error in the logs.

To check the Istio operator pod logs, run the following command.

kubectl logs -n ibm-operators -l name=addon-istio-operator
6. After you have determined which section in the IOP resource configuration caused the reconcile loop error, repeat the steps with each individual line in the section until you determine the line that is causing the error.
7. Debug the line to resolve the error.
8. Repeat the process with the remaining sections until you have copied all the original IOP configuration into the test file and determined that no errors remain.
9. Remove the test file.

kubectl remove <test_iop_name>
10. Update your original IOP resource configuration to replace the line that caused the error. Then, reapply the original IOP resource to your production cluster.

kubectl apply -f iop.yaml
Update your apps to use the IBM PSPs.









 Migration steps 

If you determine that your cluster pod security configuration does not meet the [migration pre-requisites](https://cloud.ibm.com/docs/containers?topic=containers-pod-security-admission-migrationpsa-upgrade-reqs), you must follow these migration steps to upgrade your cluster.

Several of the following Pod Security migration steps include links to sections in the Kubernetes documentation. Note that not all steps included in the external Kubernetes documentation are relevant to IBM Cloud Kubernetes Service clusters. Follow only the steps that are directly linked from this page. Do not follow the external Kubernetes migration guide in its entirety, as some actions are not appropriate for IBM Cloud Kubernetes Service clusters. Read the following steps carefully to ensure that you take the correct migration actions for your cluster.



 Step 1: Enable Pod Security admission in your 1.24 cluster 

Enable Pod Security admission in your 1.24 cluster. This command updates the cluster master to use the new Pod Security admission configuration. It may take a few minutes for the cluster master to update.

ibmcloud ks cluster master pod-security set --cluster <CLUSTER>





 Step 2: Review namespace permissions 

Review the namespace permissions in the external Kubernetes documentation. If your Kubernetes permissions are managed by IAM service roles, the Manager service role is required to create or edit namespaces and to set pod security labels.



* [Review namespace permissions](https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/review-namespace-permissions)







 Step 3: Simplify and standardize PSPs 

Clean up your Pod Security configuration by following the steps in the external Kubernetes documentation. Do not modify or delete any of the following PSPs: ibm-privileged-psp, ibm-anyuid-psp, ibm-anyuid-hostpath-psp, ibm-anyuid-hostaccess-psp and ibm-restricted-psp.
5.2.7 Red Hat OpenShift on IBM Cloud can optionally configure [OpenShift security context constraints](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_scc) and [Kubernetes pod security admission](https://kubernetes.io/docs/concepts/security/pod-security-admission/) which are similar to the deprecated [Kubernetes pod security policies](https://kubernetes.io/docs/concepts/security/pod-security-policy/). 
 5.2.8 Red Hat OpenShift on IBM Cloud can optionally configure [OpenShift security context constraints](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_scc) and [Kubernetes pod security admission](https://kubernetes.io/docs/concepts/security/pod-security-admission/) which are similar to the deprecated [Kubernetes pod security policies](https://kubernetes.io/docs/concepts/security/pod-security-policy/). 
 5.2.9 Red Hat OpenShift on IBM Cloud can optionally configure [OpenShift security context constraints](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_scc) and [Kubernetes pod security admission](https://kubernetes.io/docs/concepts/security/pod-security-admission/) which are similar to the deprecated [Kubernetes pod security policies](https://kubernetes.io/docs/concepts/security/pod-security-policy/).
Why does my pod with long running TCP connections get disconnected? 

Virtual Private Cloud

Classic infrastructure

  What’s happening 

When a pod has long running TCP connections and the pod is idle for a period of time, it occasionally gets disconnected.

  Why it’s happening 

The idle time might have exceeded the limit that is defined by the sysctl keepalive settings for the pod.

  How to fix it 

Try updating the the sysctl keepalive settings for the pod. For more information, see [Optimizing network keepalive sysctl settings](https://cloud.ibm.com/docs/containers?topic=containers-kernelkeepalive-iks).
You can call preconfigured screens with the [iOS Swift client SDK](https://github.com/ibm-cloud-security/appid-clientsdk-swift).

Place the following command in your code.

import IBMCloudAppID
class delegate : AuthorizationDelegate {
public func onAuthorizationSuccess(accessToken: AccessToken, identityToken: IdentityToken, refreshToken: RefreshToken?) {
//User authenticated
}

public func onAuthorizationCanceled() {
//Authentication canceled by the user
}

public func onAuthorizationFailure(error: AuthorizationError) {
//Exception occurred
}
}

AppID.sharedInstance.loginWidget?.launch(delegate: delegate())
Show more



 Sign up 



1. Configure your Cloud Directory [settings](https://cloud.ibm.com/docs/appid?topic=appid-cloud-directorycd-settings) in the GUI. Both Allow users to sign up to your app and Allow users to manage their account from your app must be set to On.
2. Place the following code in your application. When a user attempts to sign up for your application, the login widget is called and displays your custom sign-up page.

class delegate : AuthorizationDelegate {
public func onAuthorizationSuccess(accessToken: AccessToken?, identityToken: IdentityToken?, refreshToken: RefreshToken?, response:Response?) {
if accessToken == nil && identityToken == nil {
//email verification is required
return
}
//User authenticated
}

public func onAuthorizationCanceled() {
//Sign up canceled by the user
}

public func onAuthorizationFailure(error: AuthorizationError) {
//Exception occurred
}
}
Known issues 

Known issues are listed by the release in which they were identified.



* For the list of release notes, see [Release notes](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-release-notes-data).
* For troubleshooting information, see [Troubleshooting](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-troubleshoot).



IBM Cloud Pak for Data

The known issues that are described in this topic apply to installed deployments only.

Known issues are cumulative. Issues from previous releases persist in later releases unless otherwise noted.



 4.7.x releases 

See [Limitations and known issues in Watson Discovery](https://www.ibm.com/docs/SSQNUZ_4.7.x/svc-discovery/discovery-known-issues.html)





 4.6.x releases 

See [Limitations and known issues in Watson Discovery](https://www.ibm.com/docs/SSQNUZ_4.6.x/svc-discovery/discovery-known-issues.html)





 4.5.x releases 

See [Limitations and known issues in Watson Discovery](https://www.ibm.com/docs/SSQNUZ_4.5.x/svc-discovery/discovery-known-issues.html).





 4.0.x releases 

For more information about known issues, see the [IBM Cloud Pak for Data documentation](https://www.ibm.com/docs/SSQNUZ_4.0/svc-discovery/discovery-known-issues.html).





 4.0.9, 25 May 2022 



* Discovery generates a partial failure status message for the IBM Cloud Pak for Data Red Hat OpenShift APIs for Data Protection (OADP) backup and restore utility.



* Error: When you check the status of the OADP backup utility after using it to backup a cluster where Discovery is installed, a Phase: PartiallyFailed message is displayed. One or more Discovery components are included in the Failed list.