vania-janet/multiturn-rag-retrieval-data huggingface dataset:
See documentation about [GitHub statuses](https://docs.github.com/en/rest/reference/reposstatuses).

Required Environment Variables:

GHE_ORG= Github organization/username
GHE_REPO= Github repository
GHE_COMMIT= Github commit hash

Required Environment Variables, if you are using GitHub:

GHE_TOKEN= Github token (Optional if you are using --git-token-path)

If you are using github, use --git-token-path field to set your GitHub Token and --git-api-url field to set the # GitHub Enterprise API URL instead of GHE_TOKEN and GH_URL environment variables. If both GHE_TOKENGH_URL and --git-token-path--git-api-url pairs are provided, then --git-token-path and --git-api-url take precedence.

Options for Git:

--git-token-path (Optional) GitHub token's path
--git-api-url (Optional) GitHub API url

Running the command:

$ cocoa set-status --state="pending" --targetURL="https://cloud.ibm.com/devops/pipelines/tekton/some-toolchain/runs/some-pipelinerun/lint/lint?env_id=ibm:yp:us-south" --context="tekton/lint" --description="Tekton linter is running."





 cocoa inventory commands 



 cocoa inventory add 

Adds a value to the inventory repository. Creates a file with the name option, if it does not exist otherwise overwrites it.

Required Environment Variables:

GHE_ORG= Github Organization (required if --org option is not specified).
GHE_REPO= Github Repository (required if --repo option is not specified).

Required Environment Variables, if you are using GitHub:
Why can't my app access or write to PVCs? 

Classic infrastructure

When you mount a PVC to your pod, you might experience errors when accessing or writing to the PVC.



1.  List the pods in your cluster and review the status of the pod.

oc get pods
2.  Find the root cause for why your app can't access or write to the PVC.

oc describe pod <pod_name>

oc logs <pod_name>
3.  Review common errors that can occur when you mount a PVC to a pod.





File Storage for Classic error messages

 Symptom or error message                                                                                                                                                                Description                                                                                                                                                                                                                            Steps to resolve                                                                                                                                                             

 Your pod is stuck in a ContainerCreating state. MountVolume.SetUp failed for volume ... read-only file system.                                                                          The IBM Cloud infrastructure back end experienced network problems. To protect your data and to avoid data corruption, IBM Cloud automatically disconnected the file storage server to prevent write operations on NFS file shares.    See [File storage: File systems for worker nodes change to read-only](https://cloud.ibm.com/docs/openshift?topic=openshift-readonly_nodes)                                      
 write-permissiondon't have required permissioncan't create directory '/bitnami/mariadb/data': Permission denied                                                                         In your deployment, you specified a non-root user to own the NFS file storage mount path. By default, non-root users don't have write permission on the volume mount path for NFS-backed storage.                                      See [File storage: App fails when a non-root user owns the NFS file storage mount path](https://cloud.ibm.com/docs/openshift?topic=openshift-nonroot)  
 After you specified a non-root user to own the NFS file storage mount path or deployed a Helm chart with a non-root user ID specified, the user can't write to the mounted storage.     The deployment or Helm chart configuration specifies the security context for the pod's fsGroup (group ID) and runAsUser (user ID)                                                                                                     See [File storage: Adding non-root user access to persistent storage fails](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_storage_nonroot)
Why don't my containers start? 

 What’s happening 

You notice one or more of the following issues:



* Worker nodes are unable to create new pods. The pods deploy successfully to worker nodes, but the containers are stuck in the ContainerCreating state.
* When you run kubectl describe pod <pod> for a pod in the ContainerCreating state, you see an event similar to one of the following events.

Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "XXX": failed to request 1 IPv4 addresses. IPAM allocated only 0

desc = failed to create pod network sandbox ... error adding container to network "k8s-pod-network": cannot allocate new block due to per host block limit
* One or more of the calico-node pods fail to start on a worker node and are in the CrashLoopBackOff state. When you run kubectl logs -n kube-system <calico-node_pod>, the last lines of the logs contain the following message.

Unable to autoassign an address - pools are likely exhausted. type="ipipTunnelAddress"



 Why it’s happening 

If you don't see either of the IP address-related messages that are listed in the symptoms, your containers might not start because the registry quota was reached.

If you see either of the IP address-related messages that are listed in the symptoms, your containers might not start because the IP Address Manager (IPAM) for the Calico plug-in incorrectly detects that all pod IP addresses in the cluster are in use. Because the Calico IPAM detects no available IP addresses, it does not assign IP addresses to new pods in the cluster, and pods can't start.

 How to fix it 



 Fixing registry quota issues 

Virtual Private Cloud

Classic infrastructure

To fix registry quota issues, [free up storage in IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_quotaregistry_quota_freeup).





 Fixing IP address issues 

Virtual Private Cloud

Classic infrastructure
H1500 Addon Ready The add-on is successfully deployed and is healthy. 
 H1501, H1502, H1503 Addon Not Ready Some or all the add-on components are unhealthy. Check whether all add-on component pods are running. For example, for the Istio add-on, check whether the pods in the istio-system and ibm-operators namespaces are in a Running state by running the kubectl get pods -n NAMESPACE command. 
 H1504, H1505, H1506, H1507, H1508 Failure determining health status. The add-on health can't be determined. [Open a support case](https://cloud.ibm.com/docs/get-support?topic=get-support-using-avatar). In the description, include the error code from the health status. 
 H1509 Addon Unsupported The add-on runs an unsupported version, or the add-on version is unsupported for your cluster version. [Update your add-on to the latest version](https://cloud.ibm.com/docs/containers?topic=containers-managed-addonsupdating-managed-add-ons), or see specific update steps for [Istio](https://cloud.ibm.com/docs/containers?topic=containers-istioistio_update). 
 H1510 Cluster resources low, not enough workers in Ready state. The add-on is not ready to be used for one of the following reasons:<br><br><br><br> * The cluster does not meet the size criteria for the add-on. For example, check the size requirements for [Istio](https://cloud.ibm.com/docs/containers?topic=containers-istioistio_install).<br> * Worker nodes in your cluster are not in a Normal state. [Review the worker nodes' state and status](https://cloud.ibm.com/docs/containers?topic=containers-debug_worker_nodes).<br><br><br>
Verify that the drivers and platform software were installed by running the following command to check for a pod that begins with sgx-installer.

kubectl get pods
4. Get the logs for your sgx-installer pod to verify that you see the messages SGX driver installed and PSW installed.

kubectl logs <name_of_SGX_installer_pod>
5. Now that the drivers and platform software are installed, remove the daemon set.

kubectl delete daemonset sgx-installer



Now, you can develop your confidential computing app to use the enclave for sensitive data.

To uninstall the drivers and platform software, you can follow the same steps, but with the following installation command: kubectl create -f https://raw.githubusercontent.com/ibm-cloud-security/data-shield-reference-apps/master/scripts/sgx-driver-psw/uninstall_sgx/deployment_uninstall_sgx_iks.yaml







 Adding tags to existing clusters 

You can assign a tag to IBM Cloud Kubernetes Service clusters to help manage your IBM Cloud resources. For example, you might add key:value tags to your cluster and other cloud resources so that your billing department track resources, such as costctr:1234. Tags are visible account-wide. For more information, see [Working with tags](https://cloud.ibm.com/docs/account?topic=account-tag).

Tags are not the same thing as Kubernetes labels. [Kubernetes labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) are key:value pairs that can be used as selectors for the resources that are in your cluster, such as [adding a label to worker pool](https://cloud.ibm.com/docs/containers?topic=containers-add_workersworker_pool_labels) to [deploy an app to only certain worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-deploy_appnode_affinity).
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. 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, you might not be able to execute all the following commands.



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

kubectl get pod ibm-vpc-block-csi-controller-0 -n kube-system -o jsonpath="{.spec['containers','initContainers'].name}" | tr -s '[:space:]]' 'n'

Example output for Block Storage for VPC

csi-provisioner
csi-attacher
liveness-probe
Pod access via service account token For clusters that run Kubernetes 1.21 and later, the service account tokens that pods use to communicate with the Kubernetes API server are time-limited, automatically refreshed, scoped to a particular audience of users (the pod), and invalidated after the pod is deleted. To continue communicating with the API server, you must design your apps to read the refreshed token value on a regular basis, such as every minute. For applications that invoke the setuid internally, you must [manually set the fsGroup in the pod security context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/set-the-security-context-for-a-pod). For more information, see [Bound Service Account Tokens](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md). 
 Unsupported: Service service.alpha.kubernetes.io/tolerate-unready-endpoints annotation Services no longer support the service.alpha.kubernetes.io/tolerate-unready-endpoints annotation. The annotation has been deprecated since Kubernetes version 1.11 and has been replaced by the Servicespec.publishNotReadyAddresses field. If your services rely on this annotation, update them to use the spec.publishNotReadyAddresses field instead. For more information on this field, see [DNS for Services and Pods](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/) 







 Update after master 

The following table shows the actions that you must take after you update the Kubernetes master.



Changes to make after you update the master to Kubernetes 1.21

 Type Description 

 Unsupported:kubect alpha debug removed The kubectl alpha debug command is removed. Instead, use the kubectl debug command.
* Cause: The current code returns an error when no instance exists because it cannot find a document index to migrate.
* Solution: Verify that an instance of Discovery has been provisioned in the existing IBM Cloud Pak for Data cluster before you start the upgrade to 4.0.6. If you tried to upgrade to 4.0.6, but no instances were provisioned and the migration failed, remove the existing installation and install 4.0.6 from scratch.



* Deployed status of resources fluctuates after the 4.0.6 upgrade is completed.



* Error: When you check the status by submitting the oc get WatsonDiscovery command, the ready status of the resources toggles between showing 23/23 and 20/23 components as being ready for use.
* Cause: The readiness state of the resources is not reported consistently after a migration.
* Solution: Typically, the instance is ready for use despite the ready state instability. The ready state settles after approximately 5 hours. You can wait for the readiness state to consistently show 23/23 or you can manually refresh the status information by running the following commands in a terminal that is logged into the cluster:

oc proxy &
curl -ksS -X PATCH -H "Accept: application/json, /" -H "Content-Type: application/merge-patch+json" http://127.0.0.1:8001/apis/discovery.watson.ibm.com/v1/namespaces/<namespace>/watsondiscoveries/wd/status --data '{"status": null}'



This issue is fixed with the 4.0.8 release.
* Discovery generates an error in the IBM Cloud Pak for Data OpenShift® APIs for Data Protection (OADP) backup and restore utility.



* Error: The utility does not complete successfully and the following message is written to the log: preBackupViaConfigHookRule on backupconfig/watson-discovery in namespace cpd (status=error)
* Cause: Discovery cannot be backed up and restored by using the OADP backup and restore utility.
For a more detailed explanation of different features that you can add to your deployment, see [Making your app deployment YAML file](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_appsapp_yaml).





 What type of Kubernetes objects can I make for my app? 

When you prepare your app YAML file, you have many options to increase the app's availability, performance, and security. For example, instead of a single pod, you can use a Kubernetes controller object to manage your workload, such as a replica set, job, or daemon set. For more information about pods and controllers, view the [Kubernetes documentation](https://kubernetes.io/docs/concepts/workloads/pods/). A deployment that manages a replica set of pods is a common use case for an app.

For example, a kind: Deployment object is a good choice to deploy an app pod because with it, you can specify a replica set for more availability for your pods.

The following table describes why you might create different types of Kubernetes workload objects.



Types of Kubernetes workload objects that you can create.

 Object Description 

 [Pod](https://kubernetes.io/docs/concepts/workloads/pods/) A pod is the smallest deployable unit for your workloads, and can hold a single or multiple containers. Similar to containers, pods are disposable and are often used for unit testing of app features. To avoid downtime for your app, consider deploying pods with a Kubernetes controller, such as a deployment. A deployment helps you to manage multiple pods, replicas, pod scaling, rollouts, and more. 
 [ReplicaSet](https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/) A replica set makes sure that multiple replicas of your pod are running, and reschedules a pod if the pod goes down. You might create a replica set to test how pod scheduling works, but to manage app updates, rollouts, and scaling, create a deployment instead.
Why are no pods listed in the openshift-storage namespace? 

  What’s happening 

There are no pods listed when you run the oc get pods -n openshift-storage command. When you view the ibm-ocs-operator-controller-manager logs with the oc logs <ibm-ocs-operator-controller-manager-a1a1a1a> -n kube-system command, you see the following error message:

Failed to get StorageCluster","error":"no matches for kind "StorageCluster" in version "ocs.openshift.io/v1

  Why it’s happening 

The catalog source for your ODF storage cluster is unhealthy.

  How to fix it 

Remove all the catalog sources from your cluster.



1.  Remove all catalog sources from your cluster. A new catalog source and respective pods automatically generate.

oc -n openshift-marketplace delete catsrc --all
2.  Wait a few minutes and verify that the pods regenerate. If the pods regenerate, the ODF installation proceeds. If the pods don't regenerate, [contact ODF support by raising a case in the Red Hat customer portal](https://cloud.ibm.com/docs/openshift?topic=openshift-ocs-error-unresolved).

oc get pods,catsrc -n openshift-marketplace
Adds fix for [CVE-2021-43565](https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-43565). Adds Golang dependency updates. 
 Konnectivity agent v0.0.27_309_iks v0.0.27_a6b5248a_323_iks See the [Konnectivity release notes](https://github.com/kubernetes-sigs/apiserver-network-proxy/releases/tag/v0.0.27). Updated universal base image (UBI) to the 8.5-230 version to resolve CVEs. Updated to use Go version 1.17.5. 
 Konnectivity server v0.0.27_309_iks v0.0.27_a6b5248a_323_iks See the [Konnectivity release notes](https://github.com/kubernetes-sigs/apiserver-network-proxy/releases/tag/v0.0.27). Updated universal base image (UBI) to the 8.5-230 version to resolve CVEs. Updated to use Go version 1.17.5. 
 Kubernetes v1.23.3 v1.23.4 See the [Kubernetes release notes](https://github.com/kubernetes/kubernetes/releases/tag/v1.23.4). 







 Change log for worker node fix pack 1.23.4_1521, released 28 February 2022 



Changes since version 1.23.3_1519

 Component Previous Current Description
Troubleshooting IBM Watson® Discovery Cartridge for IBM Cloud Pak® for Data deployments 

Learn ways to troubleshoot and address issues that you might encounter while using the product.

IBM Cloud Pak for Data

This information applies only to instances of IBM Watson® Discovery that are installed on IBM Cloud Pak® for Data. For troubleshooting tips about adding data to both installed and managed deployments, see [Troubleshooting ingestion](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-troubleshoot-ingestion).

The information in this topic suggests steps you can take to investigate issues that might occur. For information about known issues and their workarounds per version, see [Known issues](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-known-issues).



 Minio pods enter a reboot loop during installation or upgrade 



* Error: Cannot find volume "export" to mount into container "ibm-minio" is displayed during an installation or upgrade of Discovery. When you check the status of the Minio pods by using the command, oc get pods -l release=wd-minio -o wide, and then check the Minio operator logs by using the commands, oc get pods -A | grep ibm-minio-operator, and then oc logs -n <namespace> ibm-minio-operator-XXXXX, you see an error similar to the following one in the logs:

ibm-minio/templates/minio-create-bucket-job.yaml failed: jobs.batch "wd-minio-discovery-create-bucket" already exists) and failed rollback: failed to replace object"
* Cause: A job that creates a storage bucket for Minio and then is deleted after it completes, is not being deleted properly.
* Solution: Complete the following steps to check whether an incomplete create-bucket job for Minio exists. If so, delete the incomplete job so that the job can be recreated and can then run successfully.



1. Check for the Minio job by using the following command:

oc get jobs | grep 'wd-minio-discovery-create-bucket'
2.
Why don't my containers start? 

 What’s happening 

You notice one or more of the following issues:



* Worker nodes are unable to create new pods. The pods deploy successfully to worker nodes, but the containers are stuck in the ContainerCreating state.
* When you run oc describe pod <pod> for a pod in the ContainerCreating state, you see an event similar to one of the following events.

Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "XXX": failed to request 1 IPv4 addresses. IPAM allocated only 0

desc = failed to create pod network sandbox ... error adding container to network "k8s-pod-network": cannot allocate new block due to per host block limit
* One or more of the calico-node pods fail to start on a worker node and are in the CrashLoopBackOff state. When you run kubectl logs -n kube-system <calico-node_pod>, the last lines of the logs contain the following message.

Unable to autoassign an address - pools are likely exhausted. type="ipipTunnelAddress"



 Why it’s happening 

If you don't see either of the IP address-related messages that are listed in the symptoms, your containers might not start because the registry quota was reached.

If you see either of the IP address-related messages that are listed in the symptoms, your containers might not start because the IP Address Manager (IPAM) for the Calico plug-in incorrectly detects that all pod IP addresses in the cluster are in use. Because the Calico IPAM detects no available IP addresses, it does not assign IP addresses to new pods in the cluster, and pods can't start.

 How to fix it 



 Fixing registry quota issues 

Virtual Private Cloud

Classic infrastructure

To fix registry quota issues, [free up storage in IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_quotaregistry_quota_freeup).





 Fixing IP address issues 

Virtual Private Cloud

Classic infrastructure
OS name: "linux", version: "4.19.76-linuxkit", arch: "amd64", family: "unix"

 gradle -version

Welcome to Gradle 6.5.1!

Here are the highlights of this release:
- Experimental file-system watching
- Improved version ordering
- New samples

For more details see https://docs.gradle.org/6.5.1/release-notes.html

------------------------------------------------------------
Gradle 6.5.1
------------------------------------------------------------

Build time: 2020-06-30 06:32:47 UTC
Revision: 66bc713f7169626a7f0134bf452abde51550ea0a

Kotlin: 1.3.72
Groovy: 2.5.11
Ant: Apache Ant(TM) version 1.10.7 compiled on September 1 2019
JVM: 11.0.7 (Eclipse OpenJ9 openj9-0.20.0)
OS: Linux 4.19.76-linuxkit amd64

 oc version
oc v3.11.0+0cbc58b
kubernetes v1.11.0+d4cacc0
features: Basic-Auth GSSAPI Kerberos SPNEGO
Show more





 Version 2.7 

Starting with version 2.7, the default JVM is Java™ 11. Java™ 8 was removed. If you still need Java™ 1.8, you can either use version 2.6 or your own custom image.