vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Referring to the image pull secret in your pod deployment 

If the cluster administrator did not [store the image pull secret in the Kubernetes service account](https://cloud.ibm.com/docs/openshift?topic=openshift-registryuse_imagePullSecret), all deployments that don't specify a service account can't use the image pull secret to deploy containers. Instead, you can define an image pull secret in your pod deployment. When you refer to the image pull secret in a pod deployment, the image pull secret is valid for this pod only and can't be shared across pods in the Red Hat OpenShift project.

Before you begin



* [Create an image pull secret](https://cloud.ibm.com/docs/openshift?topic=openshift-registryother) to access images in other registries or Red Hat OpenShift projects other than default.
* [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).



To refer to the image pull secret in your pod deployment,



1. Create a pod configuration file that is named mypod.yaml.
2. Define the pod and the image pull secret to access images in IBM Cloud Container Registry.

To access a private image,

apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: <container_name>
image: <region>.icr.io/<namespace_name>/<image_name>:<tag>
imagePullSecrets:
- name: <secret_name>

To access an IBM Cloud public image,

apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: <container_name>
image: icr.io/<image_name>:<tag>
imagePullSecrets:
- name: <secret_name>

container_name>
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 sat-aws-block-bronze
2. Remove the pod that uses the PVC. If the pod is part of a deployment, remove the deployment.

oc delete pod <pod_name>

oc delete deployment <deployment_name>
3. Verify that the pod or the deployment is removed.

oc get pods

oc get deployments



3. Delete the PVC. Because you statically provisioned the AWS EFS storage, deleting the PVC does not remove the PV or the AWS EFS instance in your AWS account.

oc delete pvc <pvc_name>
4. Delete the corresponding PV.

oc delete pv <pv_name>
5. From the [AWS EFS console](https://console.aws.amazon.com/efs/home), select the file system that you want to delete and click Delete.







 Removing the AWS EFS storage configuration from your cluster 

If you no longer plan on using AWS EFS storage in your cluster, you can unassign your cluster from the storage configuration.

Note that if you remove the storage configuration, the driver is then uninstalled from all assigned clusters. 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 AWS EFS storage configuration from the console 

Use the console to remove a storage configuration.

Note that you must delete your storage assignments before you can successfully delete your storage configuration.



1. From the Satellite storage dashboard, select the storage configuration you want to delete.
2.
View the contents of the outfile file to confirm that your app can write data to your persistent storage.

cat /mnt/azuredisk/outfile

Example output

Fri Jul 16 07:49:39 EDT 2021
Fri Jul 16 07:49:39 EDT 2021
Fri Jul 16 07:49:39 EDT 2021
9. Exit the pod.

exit







 Removing Azure Disk storage from your apps 

If you no longer need your Azure Disk configuration, you can remove your apps, PVCs, PVs, and assignment from your clusters.



1. List your PVCs and note the name of the PVC that you want to remove.

oc get pvc
2. Remove any pods that mount the PVC.



1. List all the pods that currently mount the PVC that you want to delete. If no pods are returned, you do not have any pods that currently use your PVC.

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 sat-azure-block-platinum
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. Because the Azure Disk storage classes have a Delete reclaim policy, the PV and the disks in your Azure account are automatically deleted when you delete the PVC.

oc delete pvc <pvc_name>
4.
Appends com.ibm.immutable_storage evidence to the summary.



* See [cocoa locker](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-clicocoa-locker) section on how to configure the Cloud Object Storage bucket.



* --dry-run: Has an effect when combined with --check-immutable-storage. If used, com.ibm.immutable_storage evidence is only appended to the summary but it does not get uploaded to the evidence locker.



Run the command:

$ cocoa locker evidence summary docker://us.icr.io/foo/bar@sha256:1234567812345678123456781234567812345678123456781234567812345678 docker://us.icr.io/baz/quux@sha256:1234567812345678123456781234567812345678123456781234567812345678 --scope 11a1aa11-1a11-11a1-aa11-a11a1a1111a1 --scope 22a2aa22-2a22-22a2-aa22-a22a2a2222a2

Example read from stdin:

$ cat <<EOF | cocoa locker evidence summary
docker://us.icr.io/foo/bar@sha256:1234567812345678123456781234567812345678123456781234567812345678
docker://us.icr.io/baz/quux@sha256:1234567812345678123456781234567812345678123456781234567812345678
EOF





 cocoa locker attachment get < attachment-id > 

Retrieves an attachment that was previously uploaded with cocoa locker evidence add.

Options:
Migrating from PSPs to Pod Security Admission 

[Pod Security admission](https://cloud.ibm.com/docs/containers?topic=containers-pod-security-admission&interface=ui) replaces Pod Security policies (PSPs) in clusters that run version 1.25 or later. Depending on your PSP configuration, you might need to take certain actions before upgrading your cluster from version 1.24 to 1.25.

Your cluster must meet certain PSP configuration requirements before you can upgrade from version 1.24 to 1.25. If your cluster does not meet these requirements, the upgrade is blocked. Complete the following steps to check for any custom PSPs and remove them.



* If you have not customized or altered PSPs in your cluster, you can likely upgrade your cluster. However, it is recommended that you review the requirements to make sure that you do not need to modify your PSP configuration before you upgrade your cluster.
* If you have customized or altered PSPs in your cluster, including creating your own PSPs, installing applications that create PSPs, or changing cluster role bindings to restrict the use of certain PSPs, you must modify your setup to meet the requirements for upgrading your cluster.



Before you begin, review the information under [Decide whether Pod Security admission is right for you](https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/) in the Kubernetes documentation to familiarize yourself with the differences between PSPs and Pod Security admission.



 Upgrade requirements 

You can upgrade your cluster if your cluster setup meets the following requirements. These requirements ensure that pods run properly under the default Pod Security admission configuration provided in clusters that run version 1.25. If these requirements are not met, your cluster cannot upgrade unless you take additional migration steps.



* All pods run under the ibm-privileged-psp PSP.
* The privileged-psp-user cluster role binding uses the default configuration.
* The restricted-psp-user cluster role binding uses the default configuration.
* Only the following PSPs provided by IBM Cloud are present, and no additional PSPs are configured.



* ibm-privileged-psp
* ibm-anyuid-psp
Changing the ID or domain name prevents the Kubernetes master from managing your cluster.

--disable-public-service-endpoint
: To ensure that worker nodes and authorized cluster users communicate with the master through the private cloud service endpoint only, include this option to create the cluster without the public cloud service endpoint.

--pod-subnet SUBNET
: In the first cluster that you create in a VPC, the default pod subnet is 172.17.0.0/18. In the second cluster that you create in that VPC, the default pod subnet is 172.17.64.0/18. In each subsequent cluster, the pod subnet range is the next available, non-overlapping /18 subnet. If you plan to connect your cluster to on-premises networks through IBM Cloud® Direct Link or a VPN service, you can avoid subnet conflicts by specifying a custom subnet CIDR that provides the private IP addresses for your pods.
: When you choose a subnet size, consider the size of the cluster that you plan to create and the number of worker nodes that you might add in the future. The subnet must have a CIDR of at least /23, which provides enough pod IPs for a maximum of four worker nodes in a cluster. For larger clusters, use /22 to have enough pod IP addresses for eight worker nodes, /21 to have enough pod IP addresses for 16 worker nodes, and so on. The subnet that you choose must be within one of the following ranges.



* 172.17.0.0 - 172.17.255.255
* 172.21.0.0 - 172.31.255.255
* 192.168.0.0 - 192.168.254.255
* 198.18.0.0 - 198.19.255.255



: Note that the pod and service subnets can't overlap. If you use custom-range subnets for your worker nodes, you must [ensure that your worker node subnets don't overlap with your cluster's pod subnet](https://cloud.ibm.com/docs/containers?topic=containers-vpc-subnetsvpc-ip-range).

--service-subnet SUBNET
defaultMode: 420
containers:
- name: skill-search
volumeMounts:
- name: updated-cacerts
mountPath: /opt/ibm/java/jre/lib/security/cacerts
subPath: cacerts
EOF
Show more
6. Wait until new search skill pods are created. It might take up to 10 minutes before the updates take affect.7. Check that the search skill feature is working as expected.<-- </ol> --><-- </section "id="section-apply-the-fix" "> --><-- </section "id="section-troubleshoot-150-search-skill" "> --><-- <section "id="section-troubleshoot-150-disable-hpa" "> --> Disable Horizontal Pod Autoscaling and set a maximum number of master pods Horizontal Pod Autoscaling (HPA) is enabled automatically for Watson Assistant. As a result, the number of replicas changes dynamically in the range of 1 to 10 replicas. You can disable HPA if you want to limit the maximum number of master pods or if you're concerned about master pods being created and deleted too frequently.<-- <ol> -->1. First, disable HPA for the master microservice by running the following command. In these steps, substitute your instance name for the INSTANCE_NAME variable:
oc patch wa ${INSTANCE_NAME} --type='json' --patch='{"op": "add", "path": "/appConfigOverrides/clu", "value":{"master":{"autoscaling":{"enabled":false}}}}] ! ! ! '
2. Wait until the information propagates into the Watson Assistant operator:
sleep 600
3. Run the following command to remove HPA for the master microservice
oc delete hpa ${INSTANCE_NAME}-master
4. Wait for about 30 seconds:
sleep 30
If you create this additional PSP, it must be deleted before you upgrade to version 1.25, as detailed in the [upgrade requirements](https://cloud.ibm.com/docs/containers?topic=containers-pod-security-admission-migrationpsa-upgrade-reqs). Instead, use the following command to create a RoleBinding to the ibm-privileged-psp-user cluster role: kubectl create -n $NAMESPACE rolebinding disable-psp --clusterrole ibm-privileged-psp-user --group system:serviceaccounts:$NAMESPACE.



* [Update namespaces](https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/update-namespaces)







 Step 5: Review the namespace creation process 

Review the information in the external Kubernetes documentation to ensure that the Pod Security profile is applied to any new namespaces that are created in your cluster.



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







 Step 6: Optional. Disable the PSP feature in the cluster 



1. Disable the PodSecurityPolicy admission controller in the cluster. This command updates the cluster master to use the new configuration.

ibmcloud ks cluster master pod-security policy disable --cluster <cluster>
2. Wait a few minutes for the cluster master update to complete.
3. Delete your PSPs and any associated Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings. Make sure that the components you delete do not grant any other unrelated permissions that you might need elsewhere. Do not delete the following PSPs: ibm-privileged-psp, ibm-anyuid-psp, ibm-anyuid-hostpath-psp, ibm-anyuid-hostaccess-psp and ibm-restricted-psp.
To specify a version other than the default, you must [disable automatic updates](https://cloud.ibm.com/docs/containers?topic=containers-ingress-alb-manageautoupdate) by running the [ibmcloud ks ingress alb autoupdate disable](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_alb_autoupdate_disable) command.





 Viewing supported image versions 

To list the latest three versions that are supported for each type of image, run the following command.

ibmcloud ks ingress alb versions

Example output

Kubernetes Ingress versions
1.1.2_2507_iks (default)
1.2.1_2506_iks
0.35.0_1374_iks

The Kubernetes Ingress version follows the format <community_version>_<ibm_build>_iks. The IBM build number indicates the most recent build of the Kubernetes Ingress NGINX release that IBM Cloud Kubernetes Service released. For example, the version 1.1.2_2507_iks indicates the most recent build of the 0.47.0 Ingress NGINX version. IBM Cloud Kubernetes Service might release builds of the community image version to address vulnerabilities.

For the changes that are in each version of the Ingress images, see the [Ingress version change log](https://cloud.ibm.com/docs/containers?topic=containers-cluster-add-ons-changelog).





 Reverting to an earlier version 

If your ALB pods were recently updated, but a custom configuration for your ALBs is affected by the latest image version build, you can use the [ibmcloud ks ingress alb update](https://cloud.ibm.com/docs/containers?topic=containers-ingress-alb-manageupdate-alb) command with the --version option to roll back ALB pods to an earlier, supported version.
kubectl apply -f <deployment>.yaml







 Referring to the image pull secret in your pod deployment 

If the cluster administrator did not [store the image pull secret in the Kubernetes service account](https://cloud.ibm.com/docs/containers?topic=containers-registryuse_imagePullSecret), all deployments that don't specify a service account can't use the image pull secret to deploy containers. Instead, you can define an image pull secret in your pod deployment. When you refer to the image pull secret in a pod deployment, the image pull secret is valid for this pod only and can't be shared across pods in the Kubernetes namespace.

Before you begin



* [Create an image pull secret](https://cloud.ibm.com/docs/containers?topic=containers-registryother) to access images in other registries or Kubernetes namespaces other than default.
* [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)



To refer to the image pull secret in your pod deployment,



1. Create a pod configuration file that is named mypod.yaml.
2. Define the pod and the image pull secret to access images in IBM Cloud Container Registry.

To access a private image,

apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: <container_name>
image: <region>.icr.io/<namespace_name>/<image_name>:<tag>
imagePullSecrets:
- name: <secret_name>

To access an IBM Cloud public image,

apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: <container_name>
image: icr.io/<image_name>:<tag>
imagePullSecrets:
--pipeline-id=<pipeline-id> --pipeline-run-id=<pipeline-run-id> --pipeline-run-url=<pipeline-run-url> --toolchain-crn=<toolchain-crn> Name of the toolchain cloud resource
--output=<filename> If present, the evidence will be saved to the given file.

CLI options can be also set from environment variables except for issue, log, and artifact. Multiple issues or artifacts must be provided with multiple issue or artifact flags. For example:

cocoa evidence create --artifact <url> <hash> --artifact <url> <hash> --issue <issue-url> --issue <issue-url>

artifact consists of a URL that points to the artifact file and a hash, they must be provided the same way as in the previous example.





 cocoa evidence format-summary 

Formats the evidence summary into a human readable format. It can be fed into the change request content.

Running the command:

$ cocoa evidence format-summary --input=<filepath> (default: -, referring to stdin) If present, the formatted evidence will be read from the given file.
--output=<filepath> (default: -, referring to stdout) If present, the formatted evidence will be saved to the given file.

 Reading from stdin and printing to stdout:
$ cat raw-summary.json | cocoa evidence format-summary -i - -o - | tee formatted-summary.txt
$ cat raw-summary.json | cocoa evidence format-summary | tee formatted-summary.txt
 Reading to and from file:
$ cocoa evidence format-summary --input=raw-summary.json --output=formatted-summary.txt





 cocoa evidence markdown-summary 

Formats the evidence summary into a markdown format that can be fed as a GitHub pull request comment.

The input is a raw summary and can be in one of two formats:



* Summary in JSON format (output of the cocoa evidence summarize command).
* [ibmcloud oc cluster master pod-security get](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicluster-master-pod-security-get)
* [ibmcloud oc cluster master pod-security set](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicluster-master-pod-security-set)
* [ibmcloud oc cluster master pod-security unset](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicluster-master-pod-security-unset)
* ibmcloud oc cluster master pod-security policy: View and modify the deprecated Pod Security policy configuration in supported clusters.



* [ibmcloud oc cluster master pod-security policy disable](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicluster-master-pod-security-policy-disable)
* [ibmcloud oc cluster master pod-security policy enable](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicluster-master-pod-security-policy-enable)
* [ibmcloud oc cluster master pod-security policy get](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicluster-master-pod-security-policy-get)





* cluster master private-service-endpoint: Manage the private service endpoint of a cluster.



* ibmcloud oc cluster master private-service-endpoint allowlist: Manage the private service endpoint allowlist.



* [ibmcloud oc cluster master private-service-endpoint allowlist add](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_master_pse_allowlist_add)
kubectl delete mutatingwebhookconfiguration NAME



2. If the service exists, but has no endpoints, check the health of the pods. First, get the pod labels from the service.

kubectl describe svc NAME -n NAMESPACE

Example output

Selector: app=my-webhook
3. List the pods that are using the labels. For example, the label in the following command is app=mywebhook.

kubectl get pods -n NAMESPACE -l app=my-webhook
4. Review the command output. If the pods are not healthy check the pod events, logs, worker node health, and other components to troubleshoot. For more information, see [Debugging app deployments](https://cloud.ibm.com/docs/containers?topic=containers-debug_apps).







 Disabling or removing a webhook 



1. Temporarily ignore connection and timeouts by setting the failure policy to Ignore. Edit the webhook by running the following commands.

kubectl edit validatingwebhookconfiguration NAME

kubectl edit mutatingwebhookconfiguration NAME
2. Search for failurePolicy and change the value to Ignore.
3. Save the configuration and exit the editor. If adjusting the failure policy doesn't resolve the issue, repeat the previous steps and change the value back to Fail.
4. Temporarily remove the webhook. Save the existing webhook configuration to a file before deleting it.

kubectl get validatingwebhookconfiguration NAME -o yaml > webhook-config.yaml

kubectl get mutatingwebhookconfiguration NAME -o yaml > webhook-config.yaml
5. Delete the webhook configuration.

kubectl delete validatingwebhookconfiguration NAME

kubectl delete mutatingwebhookconfiguration NAME
6.
If you do not use this option, the zones in your location are assigned names, such as zone-1.

--coreos-enabled
: Optional. Enable [Red Hat CoreOS](https://cloud.ibm.com/docs/satellite?topic=satellite-infrastructure-planinfras-plan-os) features within the Satellite location. This action cannot be undone.

--logging-account-id LOGGING_ACCOUNT
: Optional. The IBM Cloud account ID with the instance of IBM Log Analysis that you want to forward your Satellite logs to. This option is available only in select environments.

--pod-subnet SUBNET
: Optional. Specify a custom subnet CIDR to provide private IP addresses for pods. This option can be used only if you also enable Red Hat CoreOS with the --coreos-enabled option. All pods that are deployed to a worker node are assigned a private IP address in the 172.16.0.0/16 range by default. You can avoid subnet conflicts with the network that you use to connect to your location by specifying a custom subnet CIDR that provides the private IP addresses for your pods.
: When you choose a subnet size, consider the size of the cluster that you plan to create and the number of worker nodes that you might add in the future. The subnet must have a CIDR of at least /23, which provides enough pod IPs for a maximum of four worker nodes in a cluster. For larger clusters, use /22 to have enough pod IP addresses for eight worker nodes, /21 to have enough pod IP addresses for 16 worker nodes, and so on.
: The subnet that you choose must be within one of the following ranges.



* 172.16.0.0 - 172.17.255.255
* 172.21.0.0 - 172.31.255.255
* 192.168.0.0 - 192.168.254.255
* 198.18.0.0 - 198.19.255.255



: Note that the pod and service subnets can't overlap. The service subnet is in the 172.20.0.0/16 range by default.