vania-janet/multiturn-rag-retrieval-data huggingface dataset:
To save cluster resources, you can manually delete the chaincode-execution pods for the prior smart contract versions. From your cluster namespace, run the following command to see the list of chaincode-execution pods that are currently running:

kubectl get pod -n <NAMESPACE> | grep chaincode-execution | cut -d" " -f1 | xargs -I {} kubectl get po {} -n <NAMESPACE> --show-labels

Replace <NAMESPACE> with the name of your cluster namespace. Your smart contract name and version is visible in the output under the LABELS column next to chaincode-id. To delete the pod, run the following command:

kubectl delete pod <CHAINCODE-EXECUTION-POD> -n <NAMESPACE>

Replace <CHAINCODE-EXECUTION-POD> with the name of the chaincode-execution pod for the prior version of the smart contract that is visible in the output of the previous command.







 Private data 

Private data is a feature of Hyperledger Fabric networks at version 1.2 or higher and is used to keep sensitive information private from other organization members on a channel. Data privacy is achieved by using [private data collections](https://hyperledger-fabric.readthedocs.io/en/release-2.2/private-data/private-data.htmlwhat-is-a-private-data-collection). For example, several wholesalers and a set of farmers might be joined to a single channel. If a farmer and a wholesaler want to transact privately, they can create a channel for this purpose. But they can also decide to create a private data collection on the smart contract that governs their business interactions to maintain privacy over sensitive aspects of the sale, such as the price, without having to create a secondary channel. To learn more about when to use private data within a blockchain, visit the [Private Data](https://hyperledger-fabric.readthedocs.io/en/release-2.2/private-data/private-data.htmlprivate-data) concept article in the Fabric documentation.

In order to use private data with IBM Blockchain Platform, the following three conditions must be satisfied:
5.6.3 Apply Security Context to Your Pods and Containers Not Scored 2 [Fail](https://cloud.ibm.com/docs/containers?topic=containers-cis-benchmark-127cis-benchmark-remediations-127) Shared 
 5.6.4 The default namespace should not be used Scored 2 [Fail](https://cloud.ibm.com/docs/containers?topic=containers-cis-benchmark-127cis-benchmark-remediations-127) Shared 









 IBM remediations and explanations 

Review information from IBM on the CIS Benchmark results.



Explanation and remediation

 Section Remediation/Explanation 

 1.2.1 IBM Cloud Kubernetes Service utilizes RBAC for cluster protection, but allows anonymous discovery, which is considered reasonable per [CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/). 
 1.2.10 IBM Cloud Kubernetes Service does not enable the [EventRateLimit](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/eventratelimit) admission controller since it is a Kubernetes alpha feature. 
 1.2.12 IBM Cloud Kubernetes Service does not enable the [AlwaysPullImages](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/alwayspullimages) admission controller since it overrides a container's imagePullPolicy and may impact performance. 
 1.2.13 IBM Cloud Kubernetes Service can optionally configure [pod security admission](https://cloud.ibm.com/docs/containers?topic=containers-pod-security-admission), which is similar to the unsupported [Kubernetes pod security policies](https://kubernetes.io/docs/concepts/security/pod-security-policy/).
* Do not authorize all users or all service accounts to use any SCC other than the restricted (4.10 and earlier) or restricted-v2 (4.11 and later) SCCs.
* Do not change SCC authorization for service accounts in the openshift- namespaces. Red Hat OpenShift components are designed to run under specific SCCs and might not operate properly under a different SCC.







 Default Red Hat OpenShift security context constraints 

Red Hat OpenShift on IBM Cloud clusters come with the following security context constraints by default.

Do not edit existing Red Hat OpenShift or IBM SCCs settings, except for priority, users, or groups fields.



Default Red Hat OpenShift security context constraints

 SCC name Description 

 anyuid Denies access similar to the restricted SCC, but allows users to run with any UID and any GID. 
 hostaccess Allows access to all host namespaces, but still requires that pods are run with a UID and SELinux context that are allocated to the namespace.<br><br>Important: Grant this SCC for only trusted pods that require host access to namespaces, file systems, and process IDs. 
 hostmount-anyuid Denies access similar to the restricted SCC, but allows host mounts and any UID by a pod. This SCC is primarily used by the persistent volume recycler.<br><br>Important: Grant this SCC for only pods that require host file system access as any UID, including UID 0. 
 hostnetwork Allows the usage of host networking and host ports, but still requires that pods are run with a UID and SELinux context that are allocated to the namespace.<br><br>Important: Grant this SCC for only pods that require host network access. 
 node-exporter Gives the appropriate access for the built-in Prometheus node exporter. 
 nonroot Denies access similar to the restricted SCC, but allows users to run with any non-root UID. Either the user or the manifest of the container runtime must specify the UID.
oc get pods --all-namespaces -o=jsonpath='{range .items[]}{"n"}{.metadata.name}{":t"}{range .spec.volumes[]}{.persistentVolumeClaim.claimName}{" "}{end}{end}' | grep "<pvc_name>"

Example output

app ibmc-vpc-block-metro-5iops-tier
2. Remove the pod that uses the PVC. If the pod is part of a deployment or statefulset, remove the deployment or statefulset.

oc delete pod <pod_name>

oc delete deployment <deployment_name>

oc delete statefulset <statefulset_name>
3. Verify that the pod, deployment, or statefulset is removed.

oc get pods

oc get deployments

oc get statefulset



3. Delete the PVC.

oc delete pvc <pvc_name>
4. Verify that your PV is automatically removed.

oc get pv







 Removing the Block Storage for VPC storage configuration from your cluster 

If you no longer plan on using your Block Storage for VPC in your cluster, you can use the CLI unassign your cluster from the storage configuration.

Note that if you remove the storage configuration, the driver is then uninstalled from all assigned clusters. Your PVCs, PVs, and data are not removed. However, you might not be able to access your data until you re-install the driver in your cluster again.



 Removing the Block Storage for VPC storage configuration using the console 



1. From the Satellite storage dashboard, select the storage configuration you want to delete.
2. Select Actions > Delete
3. Enter the name of your storage configuration.
4. Select Delete.







 Removing the Block Storage for VPC storage configuration using the cli 



1. List your storage assignments and find the one that you used for your cluster.
Kubernetes Make sure to review the [Kubernetes project limitations](https://kubernetes.io/docs/setup/best-practices/cluster-large/). 
 KMS provider Customizing the IP addresses that are allowed to connect to your IBM® Key Protect for IBM Cloud® instance is not supported. 
 Kubernetes pod logs To check the logs for individual app pods, you can use the command line to run kubectl logs <pod name>. Do not use the Kubernetes dashboard to stream logs for your pods, which might cause a disruption in your access to the Kubernetes dashboard. 
 Load balancers Kubernetes 1.23 or later: Although the Kubernetes [SCTP protocol](https://kubernetes.io/docs/concepts/services-networking/service/sctp) is generally available in the Kubernetes community release, creating load balancers that use this protocol is not supported in IBM Cloud Kubernetes Service clusters. 
 Operating system Worker nodes must run RHEL 7 . You can't create a cluster with worker nodes that run different types of operating systems, such as Red Hat OpenShift on Red Hat Enterprise Linux and community Kubernetes on Ubuntu.Ubuntu 16 is deprecated. Before the end of support on 31 December 2021, [update the worker pools in your cluster to run Ubuntu 18](https://cloud.ibm.com/docs/containers?topic=containers-updatemachine_type). For more information, see the [IBM Cloud blog](https://www.ibm.com/cloud/blog/announcements/new-bare-metal-servers-available-for-kubernetes-and-openshift-clusters). 
 Pod instances You can run 110 pods per worker node. If you have worker nodes with 11 CPU cores or more, you can support 10 pods per core, up to a limit of 250 pods per worker node. The number of pods includes kube-system and ibm-system pods that run on the worker node. For improved performance, consider limiting the number of pods that you run per compute core so that you don't overuse the worker node.
Depending on your requirements, you must either delete the resource from the resource reclamations, or select a different data center (maximum number of servers is reached), or select the appropriate paid plan that meets your requirements if you reach the maximum number of free plans. For more information, see [resource reclamations](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_commands_resourceibmcloud_resource_reclamations).





 VoiceOver on MacOS does not announce all information on the dashboard in Firefox 

VoiceOver on MacOS does not announce information presented on the dashboard in Firefox. It does not announce the public IP address, the internal IP address, the command how to connect to a virtual server, the initial SSH public key fingerprint, the image name, the image type, the operating system.

 What’s happening 

You try to announce the information presented on the dashboard using VoiceOver on MacOS in Firefox. No information is announced.

 Why it’s happening 

Firefox does not fully support assistive technology. For more information, see [Proper voiceover support coming soon](https://blog.mozilla.org/accessibility/proper-voiceover-support-coming-soon-to-firefox-on-macos/).

 How to fix it 

Use VoiceOver with either Safari or Chrome.
You can still deploy apps while disconnected by using the Kubernetes API. Equal to the accessTokenMaxAgeSeconds from last authentication 
 Removal You can remove apps by using your preferred methods, such as kubectl command line, the OpenShift Console, CI/CD pipelines, and Sat Config. You can still remove apps while disconnected by using the Kubernetes API. Equal to the accessTokenMaxAgeSeconds from last authentication 
 Scaling You can scale apps by using your preferred methods, such as kubectl command line, the OpenShift Console, CI/CD pipelines, and Sat Config. You can still scale apps while disconnected by using the Kubernetes API. Equal to the accessTokenMaxAgeSeconds from last authentication 







 IBM Cloud Catalog disconnected usage 



Disconnected Cloud Catalog management

 Feature Connected behavior Disconnected behavior Maximum disconnection tolerance 

 Managing resources from the IBM Cloud Catalog Search for and deploy resources from the catalog. You cannot search for and deploy resources from the catalog. Zero 







 Identity and access management disconnected usage 



Disconnected identity and access management

 Feature Connected behavior Disconnected behavior Maximum disconnection tolerance 

 Authorization Define user access roles by using IAM You can't manage user access Equal to the accessTokenMaxAgeSeconds from last authentication 
 Authentication Authenticate to IBM Cloud by using IAM You can't re-authenticate Equal to the accessTokenMaxAgeSeconds from last authentication 







 Secret management disconnected usage 



Disconnected secret management

 Feature Connected behavior Disconnected behavior Maximum disconnection tolerance 

 Secret and key management using Secret Manager You can use Secret Manager for your secrets. Secrets Manager is not available Zero 







 Logging and monitoring disconnected usage 



Disconnected logging and monitoring

 Feature Connected behavior Disconnected behavior Maximum disconnection tolerance 

 Application, audit and access logging with IBM Cloud Activity Tracker -- -- -- 
 Application monitoring with IBM Cloud Monitoring -- -- -- 
 Application logging using other provider You can use third-party logging tools. No impact. Equal to the accessTokenMaxAgeSeconds from last authentication 
 System/Kubernetes logging using other provider You can use third-party logging tools. No impact.
But when you deploy an app to your cluster, you don't want to rely on the pod IP address for service discovery and networking. Pods are removed and replaced frequently and dynamically. Instead, use a Kubernetes service, which represents a group of pods and provides a stable entry point through the service's virtual IP address, called its cluster IP. For more information, see the Kubernetes documentation on [Services](https://kubernetes.io/docs/concepts/services-networking/service/discovering-services).



 How can I make sure that my services are connected to the correct deployments and ready to go? 

For most services, add a selector to your service .yaml file so that it applies to pods that run your apps by that label. Many times when your app first starts up, you don't want it to process requests immediately. Add a readiness probe to your deployment so that traffic is only sent to a pod that is considered ready. For an example of a deployment with a service that uses labels and sets a readiness probe, check out this [NGINX YAML](https://raw.githubusercontent.com/IBM-Cloud/kube-samples/master/deploy-apps-clusters/nginx_preferredAntiAffinity.yaml).

Sometimes, you don't want the service to use a label. For example, you might have an external database or want to point the service to another service in a different namespace within the cluster. When this happens, you have to manually add an endpoints object and link it to the service.





 How can I expose my services on the Internet? 

You can create three types of services for external networking: NodePort, LoadBalancer, and Ingress.

You have different options that depend on your cluster type. For more information, see [Planning networking services](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planningexternal).
The default value is false.

--build-clear, --bc
: Remove the association of a build from this application. The build clear option is allowed only if your app currently has an associated build. This value is optional. The default value is false.

--build-commit, --commit, --bcm, --cm, --revision
: The commit, tag, or branch in the source repository to pull. The build commit option is allowed only if the --build-source option is set to the URL of a Git repository on this app update command, or your application currently has an associated build from a Git repository source. This value is optional.

--build-commit-clear, --commit-clear, --bcmc, --cmc
: Clear the commit, tag, or branch in the source repository to pull. The commit clear option is allowed if your application currently has an associated build. This value is optional. The default value is false.

--build-context-dir, --context-dir, --bcdr, --cdr
: The directory in the repository that contains the buildpacks file or the Dockerfile. The build context directory option is allowed if the --build-source option is set on this app update command, or your application currently has an associated build. This value is optional.

--build-dockerfile, --dockerfile, --bdf, --df
: The path to the Dockerfile. Specify this option only if the name is other than Dockerfile. The build dockerfile option is allowed only if the --build-source option is set on this app update command, or your application currently has an associated build. This value is optional. The default value is Dockerfile.

--build-git-repo-secret, --git-repo-secret, --bgrs, --grs, --repo
: The name of the SSH secret, which contains the credentials to access the private repository that contains the source code to build your container image.
: Note that the pod and service subnets can't overlap. The pod subnet is in the 172.30.0.0/16 range by default.

--skip-advance-permissions-check
: Optional: Skip [the check for infrastructure permissions](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cliinfra_permissions_get) before creating the cluster. Note that if you don't have the correct infrastructure permissions, the cluster creation might only partially succeed, such as the master provisioning but the worker nodes unable to provision. You might skip the permissions check if you want to continue an otherwise blocked operation, such as when you use multiple infrastructure accounts and can handle the infrastructure resources separately from the master, if needed later.

-q
: Optional: Do not show the message of the day or update reminders.



 Example cluster create classic commands 

Create a free cluster: Specify the cluster name only; everything else is set to a default value. A free cluster is automatically deleted after 30 days. You can have one free cluster at a time. To take advantage of the full capabilities of Kubernetes, create a standard cluster.

ibmcloud ks cluster create classic --name my_cluster

Create your first standard cluster: The first standard cluster that is created in a zone also creates a private VLAN. Therefore, don't include the --public-vlan option.

ibmcloud ks cluster create classic --zone dal10 --private-vlan my_private_VLAN_ID --flavor b3c.4x16 --name my_cluster --hardware shared --workers 2 --operating-system UBUNTU_20_64

Create subsequent standard clusters: If you already created a standard cluster in this zone or created a public VLAN in IBM Cloud infrastructure before, specify that public VLAN with the --public-vlan option. To find out whether you already have a public VLAN for a specific zone or to find the name of an existing public VLAN, run ibmcloud ks vlan ls --zone <zone>.
Why does block storage change to read-only? 

Virtual Private Cloud

Classic infrastructure

 What’s happening 

You might see the following symptoms:



* When you run oc get pods -o wide, you see that multiple pods on the same worker node are stuck in the ContainerCreating or CrashLoopBackOff state. All these pods use the same block storage instance.
* When you run a oc describe pod command, you see the following error in the Events section: MountVolume.SetUp failed for volume ... read-only.



 Why it’s happening 

If a network error occurs while a pod writes to a volume, IBM Cloud infrastructure protects the data on the volume from getting corrupted by changing the volume to a read-only mode. Pods that use this volume can't continue to write to the volume and fail.

 How to fix it 

Verify the plug-in version, re-create your app, and safely reload your worker node.



1. Check the version of the IBM Cloud Block Storage plug-in that is installed in your cluster.

helm list --all-namespaces
2. Verify that you use the [latest version of the IBM Cloud Block Storage plug-in](https://cloud.ibm.com/kubernetes/helm/iks-charts/ibmcloud-block-storage-plugin). If not, [update your plug-in](https://cloud.ibm.com/docs/containers?topic=containers-block_storageupdate_block).
3. If you used a Kubernetes deployment for your pod, restart the pod that is failing by removing the pod and letting Kubernetes re-create it. If you did not use a deployment, retrieve the YAML file that was used to create your pod by running oc get pod <pod_name> -o yaml >pod.yaml. Then, delete and manually re-create the pod.

oc delete pod <pod_name>
4. Check whether re-creating your pod resolved the issue. If not, reload the worker node.



1.
* [Deleting RBAC resources](https://cloud.ibm.com/docs/containers?topic=containers-pspdelete_rbac)
* [Creating your own pod security policy](https://cloud.ibm.com/docs/containers?topic=containers-pspcreating_security_policy)



* [Understanding default resources for IBM cluster management](https://cloud.ibm.com/docs/containers?topic=containers-pspibm_psp)



[Setting pod priority](https://cloud.ibm.com/docs/containers?topic=containers-pod_prioritypod_priority)



* [Understanding default priority classes](https://cloud.ibm.com/docs/containers?topic=containers-pod_prioritydefault_priority_class)
* [Creating a priority class](https://cloud.ibm.com/docs/containers?topic=containers-pod_prioritycreate_priority_class)
* [Assigning priority to your pods](https://cloud.ibm.com/docs/containers?topic=containers-pod_priorityprioritize)



[Setting Kubernetes API priority and fairness](https://cloud.ibm.com/docs/containers?topic=containers-kubeapi-prioritykubeapi-priority)



* [Reviewing default flow schema and priority levels](https://cloud.ibm.com/docs/containers?topic=containers-kubeapi-prioritykubeapi-default-priority)



* [Viewing IBM Cloud Kubernetes Service created priority level configurations](https://cloud.ibm.com/docs/containers?topic=containers-kubeapi-prioritykube-api-prioritylevelconfig)





[Pod security admission](https://cloud.ibm.com/docs/containers?topic=containers-pod-security-admissionpod-security-admission)



* [Understanding security profiles](https://cloud.ibm.com/docs/containers?topic=containers-pod-security-admissionpod_security_profiles)
podSelector:
matchLabels:
app: Srv1
Tier: backend
ingress:
- from:
- NamespaceSelector:
matchLabels:
usage: finance
ports:
port: 3111
Show more

The spec.podSelector.matchLabels section lists the labels for the Srv1 back-end service so that the policy applies only to those pods. The spec.ingress.from.NamespaceSelector.matchLabels section lists the label for the finance namespace so that ingress is permitted only from services in that namespace.

Traffic can now flow from finance microservices to the accounts Srv1 back end. The accounts Srv1 back end can respond to finance microservices, but can't establish a reverse traffic connection.

In this example, all traffic from all microservices in the finance namespace is permitted. You can't allow traffic from specific app pods in another namespace because podSelector and namespaceSelector can't be combined.
5.6.3 Apply Security Context to Your Pods and Containers Not Scored 2 [Fail](https://cloud.ibm.com/docs/openshift?topic=openshift-cis-benchmark-412ibm-remediations-and-explanations-412) Shared 
 5.6.4 The default namespace should not be used Scored 2 Pass Shared 







 IBM remediations and explanations 



Explanations and remediations

 Section Remediation/Explanation 

 1.2.1 Red Hat OpenShift on IBM Cloud utilizes RBAC for cluster protection, but allows anonymous discovery, which is considered reasonable per [CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/). 
 1.2.10 Red Hat OpenShift on IBM Cloud does not enable the [EventRateLimit](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/eventratelimit) admission controller since it is a Kubernetes alpha feature. 
 1.2.12 Red Hat OpenShift on IBM Cloud does not enable the [AlwaysPullImages](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/alwayspullimages) admission controller since it overrides a container's imagePullPolicy and may impact performance. 
 1.2.13 Red Hat OpenShift on IBM Cloud supports [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/).