vania-janet/multiturn-rag-retrieval-data huggingface dataset:
--repo (Required) Name of the evidence locker repo, defaults to EVIDENCE_LOCKER_REPO_NAME
--git-provider Git service provider ("github")
--git-token-path Git token path to read the secret from
--git-api-url Github API URL
--config-path (required) use this path to read the config file of all the required evidence check
--summary-path (required) use this path to read the summary file of all the evidences
--pre-deployment If present, will check only pre deployment checks, defaults to false
--post-deployment If present, will check only post deployment checks, defaults to false

Run the command:

cocoa locker evidence check --summary-path=<summary-path> --config-path=<config-path> --pre-deployment --post-deployment





 cocoa locker evidence publish 

Publish the evidence to Git and the Cloud Object Storage (COS) back end (if COS is configured).

cocoa locker evidence publish is used for batch processing of evidence.

Required environment variables to configure COS:

COS_API_KEY= Cloud Object Storage API Key
COS_BUCKET_NAME= Bucket Name where the evidence will be uploaded in the COS Instance
COS_ENDPOINT= The COS API Endpoint matching the region where the bucket is located

Options:

--version Show version number
--help Show help
--git-provider Git provider of the evidence locker ("github", "gitlab")
--org (Required) Owner of the evidence locker repo, defaults to EVIDENCE_LOCKER_REPO_OWNER
--repo (Required) Name of the evidence locker repo, defaults to EVIDENCE_LOCKER_REPO_NAME
--git-token-path Git token path to read the secret from
--git-api-url Git API URL
--evidences-path (Required) Use this path to read the evidences to be published
);

When the tokens are valid, the next middleware in the request chain is called and the appIdAuthorizationContext property is added to the request object. The property contains the original access and identity tokens and the decoded payload information of the tokens.







 Protecting resources by using the Swift SDK 

The App ID server-side Swift SDK provides an API protection middleware plug-in that is used to protect your backend apps. By associating your APIs with the middleware, you can protect your app from unauthorized access. After the API is protected, the middleware ensures that the tokens that are generated by App ID are validated. You can then modify the behavior of the API depending on the validation results.

import Foundation
import Kitura // server
import Credentials // middleware
import IBMCloudAppID // SDK

// setup routes
let router = Router()

// mandatory option to be passed in if app not deployed on IBM Cloud
let options = [
"oauthServerUrl": "https://us-south.appid.cloud.ibm.com/oauth/v4/d8438de6-c325-4956-ad34-abd49194affd",
]
let apiCreds = Credentials()

// Minimum macOS version required
if available(OSX 10.12, ) {

// setup API protection
let apiKituraCredentialsPlugin = APIKituraCredentialsPlugin(options: options)
apiCreds.register(plugin: apiKituraCredentialsPlugin)

// associate route with API protection
router.all(middleware: apiCreds)

// create protected API
router.get("/protectedendpoint") { request, response, next in

response.headers["Content-Type"] = "text/html; charset=utf-8"
do {
if let userProfile = request.userProfile {
try response.status(.OK).send(
Debugging webhooks 

 What’s happening 

When running kubectl commands, you see error messages similar to the following examples.

Error from server (InternalError): error when creating "testjob.yaml": Internal error occurred: failed calling webhook "mywebhook.test.io": Post https://admission-webhook.default.svc:443/validate?timeout=30s: dial tcp 172.21.189.228:443: connect: connection timed out

error creating namespace "test": Internal error occurred: admission plugin "MutatingAdmissionWebhook" failed to complete mutation in 13s

Failing webhooks might also cause problems similar to the following issues.



* You can't create or modify pods, secrets, or namespaces.
* You can't add worker nodes to a cluster or create a secret that holds the LUKS encryption key.
* You can't patch, update, or upgrade and the underlying failure is related to creating resources in the cluster.



 Why it’s happening 

A problem in the called service or the secure tunnel can cause requests to fail due to timeouts. You might be unaware that you have admission control webhooks installed until this happens.

Admission control webhooks provide the ability to validate or modify, or mutate, Kubernetes API requests. These webhooks are called from the cluster apiserver or openshift-apiserver and typically call a service running in the cluster. Admission control webhooks have rules defining the kind of resource such as pod, namespace, etc and the operation they are called for such as create, update, delete (CRUD).

Webhooks have a failure policy that indicates whether Kubernetes can ignore connection errors when calling the webhook or whether connection error must fail the operation. A ValidatingWebhookConfiguration resource inspects the request while a MutatingWebhookConfiguration resource modifies the request data before it is processed.

Webhooks can also deny requests as part of normal operation: A webhook might deny requests that violate security policies or it might perform other data validation.
* If the status of the PVC shows Pending, describe the PVC and review the Events section of the output for any warnings or error messages. Note that PVCs that reference storage classes with the volume binding mode set to WaitForFirstConsumer remain Pending until an app pod is deployed that uses the PVC.

kubectl describe pvc <pvc_name>

Example output

Name: local-pvc
Namespace: default
StorageClass: sat-local-file-gold
Status: Pending
Volume:
Labels: <none>
Annotations: <none>
Finalizers: [kubernetes.io/pvc-protection]
Capacity:
Access Modes:
VolumeMode: Filesystem
Mounted By: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning ProvisioningFailed 60s (x42 over 11m) persistentvolume-controller storageclass.storage.k8s.io "sat-local-file-gold" not found



2. [Review the Block Storage for Classic troubleshooting documentation for steps to resolve common errors](https://cloud.ibm.com/docs/containers?topic=containers-cs_sitemapsitemap_block_storage).







 Checking and updating the kubectl CLI version 

If you use a kubectl CLI version that does not match at least the major.minor version of your cluster, you might experience unexpected results. For example, [Kubernetes does not support](https://kubernetes.io/releases/version-skew-policy/)kubectl client versions that are 2 or more versions apart from the server version (n +/- 2).



1. Verify that the kubectl CLI version that you run on your local machine matches the Kubernetes version that is installed in your cluster. Show the kubectl CLI version that is installed in your cluster and your local machine.

kubectl version

Example output:
You must remove the PVC, PV, and the physical storage separately.

If your storage is charged monthly, you still get charged for the entire month, even if you remove the storage before the end of the billing cycle.
3. Remove any pods that mount the PVC. List the pods that mount the PVC. If no pod is returned in your CLI output, you don't have a pod that uses the PVC.

kubectl get pods --all-namespaces -o=jsonpath='{range .items[]}{"n"}{.metadata.name}{":t"}{range .spec.volumes[]}{.persistentVolumeClaim.claimName}{" "}{end}{end}' | grep "<pvc_name>"

Example output

blockdepl-12345-prz7b: claim1-block-bronze
4. Remove the pod that uses the PVC. If the pod is part of a deployment, remove the deployment.

kubectl delete pod <pod_name>
5. Verify that the pod is removed.

kubectl get pods
6. Remove the PVC.

kubectl delete pvc <pvc_name>
7. Review the status of your PV. Use the name of the PV that you retrieved earlier as VOLUME. When you remove the PVC, the PV that is bound to the PVC is released. Depending on how you provisioned your storage, your PV goes into a Deleting state if the PV is deleted automatically, or into a Released state, if you must manually delete the PV. Note: For PVs that are automatically deleted, the status might briefly say Released before it is deleted. Rerun the command after a few minutes to see whether the PV is removed.

kubectl get pv <pv_name>
8. If your PV is not deleted, manually remove the PV.

kubectl delete pv <pv_name>
9. Verify that the PV is removed.

kubectl get pv
10.
event-notifications.00003E ERROR Notification dispatch failed due to the authentication error for device id <device_id> and platform <platform_name>. 
 event-notifications.00004E ERROR Slack returned with an error response: <error_message> with the status code: 401 
 event-notifications.00005E ERROR Notification dispatch failed due to the <'BadDeviceToken'> error for device id <device_id> and platform <platform_name>. 
 event-notifications.00006E ERROR Microsoft teams API returned with an error response: Unauthorised with the status code: 401 







 Analyzing logs 



 List logs generated by a service 

If you want to view all the logs thar are being generated for a particular source, get the sourceID from the Event Notifications service dashboard and use the following query in Log Analysis:

sourceID:<source_crn>





 List logs for a notification request 

If you know the notification ID that is generated for a request from a service or source to the Event Notifications service, use the following query in Log Analysis to list all logs for that particular notification ID:

notificationID:<notification Id>
The ${release-name} is watson-assistant. The shortened name is watson-ass.
* proxy: These pods are the entry point that is used by the Store microservice. The proxy pods route traffic to the coordinator keeper pod.
* sentinel: These pods are the ones that decide which of the keepers is the coordinator.



To manage the PostgreSQL cluster, use stolonctl commands inside the keeper pods. The metadata about the PostgreSQL configuration is stored in the configmap named stolon-cluster-${release-name}.

Postgres is used by the Store microservice to store assistants, skills, and workspaces. If PostgreSQL and the Store microservice are running, even if nothing else is working, you can export your skills from the product and save them.

During installation, the Postgres database is created. The Store microstore user is also created. You can specify the name of the database, the name of the user, and a corresponding password if you want by overriding configuration settings in the values.yaml configuration file.

The following table lists the configuration settings that are used by the Store microservice to connect to the PostgresSQL and for PostgreSQL initialization at installation time.



Postrgres datasource configuration settings

 Configuration setting name Description Default value 

 global.postgres.store.auth.user Username that is used by the Store microservice store_icp_${release-name} 
 global.postgres.store.auth.authSecretName Name of the kubernetes secret with password for the Store user. The default value is null because a password is randomly generated. null 
 global.postgres.store.database Name of the database that is used by the Store microservice conversation_icp_${release-name} 









 Model mesh 

The TAS and ED-MM microservices use a model-mesh pattern. In model mesh, each pod contains a set of loaded NLP models. Managing where models are loaded is handled by a model-mesh library.
appIdAuthContext.accessTokenPayload; // Decoded access_token JSON
appIdAuthContext.identityToken; // Raw identity_token
appIdAuthContext.identityTokenPayload; // Decoded identity_token JSON
appIdAuthContext.refreshToken; // Raw refresh_token
...
}
);

// iOS Swift example

class delegate : TokenResponseDelegate {
public func onAuthorizationSuccess(accessToken: AccessToken?, identityToken: IdentityToken?, refreshToken: RefreshToken?, response:Response?) {
//User authenticated
}

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

AppID.sharedInstance.signinWithResourceOwnerPassword(username: username, password: password, delegate: delegate())

// Server-side swift example

let options = [
"clientId": "<clientID>",
"secret": "<secret>",
"tenantId": "<tenantID>",
"oauthServerUrl": "<oauthServerURL>",
"redirectUri": "<appURL>" + CALLBACK_URL
]
let webappKituraCredentialsPlugin = WebAppKituraCredentialsPlugin(options: options)
let kituraCredentials = Credentials()
kituraCredentials.register(plugin: webappKituraCredentialsPlugin)



4. By using the attributes endpoint, make a PUT request.



* Curl
* Java
* Node
* Swift
* Swift



curl -X PUT "https://<region>.appid.cloud.ibm.com/api/v1/attributes/<attributeName>" -H "Authorization: Bearer <token>" -d "<attributeValue>"
The alert definition must be saved for alerts to be sent to your webhook.







 How to add additional fields to the webhook body 

If you need additional fields to be included in your webhook body and the JSON tokens that are provided are not enough, try the following:



1. Set the line template of the view where you configure a webhook notification so that it includes the additional data that you need in your webhook body. For more information, see [Guidelines defining line templates](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-viewsviews_line).
2. Add to your webhook body the JSON token {{ line }} so that the information is included.
--repo (Required) Name of the evidence locker repo, defaults to EVIDENCE_LOCKER_REPO_NAME
--git-provider Git service provider ("github")
--version Show version number
--git-token-path Git token path to read the secret from
--git-api-url Github API url
--format Output format ("json", default: "json")

Run the command:

cocoa locker evidence get 0000000011111111222222223333333344444444555555556666666677777777

Example output:

{
"id": "0000000011111111222222223333333344444444555555556666666677777777",
"evidence_type_id": "image_signing",
"evidence_type_version": "1.0.0",
"date": "2021-09-08T10:10:43.955Z",
"origin": {
"toolchain_crn": "crn:v1:bluemix:public:toolchain:us-south:a/111111111111c2f2222222222b22a7a63:ac2a22a2-2a2a-2222-aaa2-222aa22a2a2a::",
"pipeline_run_id": "f333b3bc-3333-3fea-3333-333d3a3b33b3",
"pipeline_id": "444aaa4a-b4c4-4444-4f4b-aa4444a444a4"
},
"details": {
"result": "success"
},
"issues": [],
"attachments": {
Instead, you can use [Kubernetes admission webhooks](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/).<br><br><br> 
 Kubernetes DNS autoscaler 1.3.0 1.4.0 See the [Kubernetes DNS autoscaler release notes](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler/releases/tag/1.4.0). 
 Kubernetes feature gates configuration N/A N/A <br><br> * Added RuntimeClass=false to disable selection of the container runtime configuration.<br> * Removed ExperimentalCriticalPodAnnotation=true because the scheduler.alpha.kubernetes.io/critical-pod pod annotation is no longer supported. Instead, you can use [Kubernetes pod priority](https://cloud.ibm.com/docs/containers?topic=containers-pod_prioritypod_priority).<br><br><br> 
 Trusted compute agent e132aa4 e7182c7 Updated image for [CVE-2019-11068](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11068).
Debugging webhooks 

 What’s happening 

When running oc commands, you see error messages similar to the following examples.

Error from server (InternalError): error when creating "testjob.yaml": Internal error occurred: failed calling webhook "mywebhook.test.io": Post https://admission-webhook.default.svc:443/validate?timeout=30s: dial tcp 172.21.189.228:443: connect: connection timed out

error creating namespace "test": Internal error occurred: admission plugin "MutatingAdmissionWebhook" failed to complete mutation in 13s

Failing webhooks might also cause problems similar to the following issues.



* You can't create or modify pods, secrets, or namespaces.
* You can't add worker nodes to a cluster or create a secret that holds the LUKS encryption key.
* You can't patch, update, or upgrade and the underlying failure is related to creating resources in the cluster.



 Why it’s happening 

A problem in the called service or the secure tunnel can cause requests to fail due to timeouts. You might be unaware that you have admission control webhooks installed until this happens.

Admission control webhooks provide the ability to validate or modify, or mutate, Kubernetes API requests. These webhooks are called from the cluster apiserver or openshift-apiserver and typically call a service running in the cluster. Admission control webhooks have rules defining the kind of resource such as pod, namespace, etc and the operation they are called for such as create, update, delete (CRUD).

Webhooks have a failure policy that indicates whether Kubernetes can ignore connection errors when calling the webhook or whether connection error must fail the operation. A ValidatingWebhookConfiguration resource inspects the request while a MutatingWebhookConfiguration resource modifies the request data before it is processed.

Webhooks can also deny requests as part of normal operation: A webhook might deny requests that violate security policies or it might perform other data validation.
For more information regarding Firefox body, follow this documentation [here](https://developer.mozilla.org/en-US/docs/Web/API/Notification).

You can follow these examples for quick start:

"ibmenfirefoxbody": "{"title":"Hello Firefox", "options": {}}"





 ibmensafaribody(string/json) 

This attribute is needed if you want to send push notification to a Safari device. This is the body that you want to send to web server, this must be JSON in string format. For more information regarding Safari body, follow this documentation [here](https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/NotificationProgrammingGuideForWebsites/PushNotifications/PushNotifications.html//apple_ref/doc/uid/TP40013225-CH3-SW1).

You can follow these examples for quick start:

"ibmensafaribody": "{"aps":{"alert":{"title":"Shipment Order 1832128321 Delevered","body":"Shipment Order 1832128321 Delevered.","action":"View"},"url-args":["1832128321"]}}"





 ibmenpushto(string/json) 

This attribute is mandatory for successful delivery from an Android FCM or APNS destination

This contains details about the destination where you want to send push notification. This field is also string format of JSON and further contains following field



* user_id – Useridto be associated with the device. where you want to target your notification
* tag – This is used to send notifications on registered tags
* platform - You can target all registered device by platforms.



Following are the corresponding platform values for each type of target.



* FCM: push_android
* APNS: push_ios
* Chrome: push_chrome
* Firefox: push_firefox
* Safari: push_safari
* Set pod [anti-affinity scheduling rules](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_appsaffinity) to prefer that your webhook pods run on different worker nodes and zones when possible. You might use [pod topology](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/) instead. However, avoid [taints](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) or forced affinity that might restrict where the webhook pods can be scheduled.
* [Set pod priority](https://cloud.ibm.com/docs/openshift?topic=openshift-pod_priority) to system-cluster-critical for the webhook pods so that other pods can't take resources from your webhook pods.
* Scope your webhook to the appropriate project. Avoid webhooks that process resources that run in system-critical projects that are set up in your cluster by default, such as kube-system, ibm-system, ibm-operators, calico-system, tigera-operator and openshift- projects.
* Review the namespaceSelector option. You can add labels to the certain critical namespaces, such as kube-system, so the webhook is not called for these cases. This setup is called an "opt out" style configuration. Or, you can configure the namespaceSelector option so the webhook is called only for namespaces that have a specific label. This setup is called an "opt in" configuration. Depending on the purpose of the webhook, it might be important that the webhook be called for all namespaces. Review the namespaceSelector configuration options in the [Kubernetes documentation](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/matching-requests-namespaceselector) and adjust your webhook configuration.
if err = nil {
panic(err)
}
b, _ := json.MarshalIndent(allDocsResult1, "", " ")
fmt.Println(string(b))

// get me 5 documents between _id order00057 --> order00077
postAllDocsOptions2 := cloudantv1.PostAllDocsOptions{
Db: core.StringPtr("orders"),
StartKey: core.StringPtr("order00057"),
EndKey: core.StringPtr("order00077"),
Limit: core.Int64Ptr(5),
}
allDocsResult2, response2, err := service.PostAllDocs(postAllDocsOptions2)
if err = nil {
panic(err)
}
b, _ := json.MarshalIndent(allDocsResult2, "", " ")
fmt.Println(string(b))

// get me 5 documents up to _id order00077
postAllDocsOptions3 := cloudantv1.PostAllDocsOptions{
Db: core.StringPtr("orders"),
EndKey: core.StringPtr("order00077"),
Limit: core.Int64Ptr(5),
}
allDocsResult3, response3, err := service.PostAllDocs(postAllDocsOptions3)
if err = nil {
panic(err)
}
b, _ := json.MarshalIndent(allDocsResult3, "", " ")
fmt.Println(string(b))
The previous Go example requires the following import block: import (
"encoding/json"
"fmt"
"github.com/IBM/cloudant-go-sdk/cloudantv1"
* If the status of the PVC shows Pending, describe the PVC and review the Events section of the output for any warnings or error messages. Note that PVCs that reference storage classes with the volume binding mode set to WaitForFirstConsumer remain Pending until an app pod is deployed that uses the PVC.

oc describe pvc <pvc_name>

Example output

Name: local-pvc
Namespace: default
StorageClass: sat-local-file-gold
Status: Pending
Volume:
Labels: <none>
Annotations: <none>
Finalizers: [kubernetes.io/pvc-protection]
Capacity:
Access Modes:
VolumeMode: Filesystem
Mounted By: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning ProvisioningFailed 60s (x42 over 11m) persistentvolume-controller storageclass.storage.k8s.io "sat-local-file-gold" not found



2. [Review the Block Storage for Classic troubleshooting documentation for steps to resolve common errors](https://cloud.ibm.com/docs/openshift?topic=openshift-sitemapsitemap_block_storage).







 Checking and updating the oc CLI version 

If you use a oc CLI version that does not match at least the major.minor version of your cluster, you might experience unexpected results. For example, [Kubernetes does not support](https://kubernetes.io/releases/version-skew-policy/)oc client versions that are 2 or more versions apart from the server version (n +/- 2).



1. Verify that the oc CLI version that you run on your local machine matches the Kubernetes version that is installed in your cluster. Show the oc CLI version that is installed in your cluster and your local machine.

oc version

Example output:
OS name: "linux", version: "5.10.104-linuxkit", arch: "amd64", family: "unix"

 gradle -version

Welcome to Gradle 7.5!

Here are the highlights of this release:
- Support for Java 18
- Support for building with Groovy 4
- Much more responsive continuous builds
- Improved diagnostics for dependency resolution

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

------------------------------------------------------------
Gradle 7.5
------------------------------------------------------------

Build time: 2022-07-14 12:48:15 UTC
Revision: c7db7b958189ad2b0c1472b6fe663e6d654a5103

Kotlin: 1.6.21
Groovy: 3.0.10
Ant: Apache Ant(TM) version 1.10.11 compiled on July 10 2021
JVM: 17.0.3 (Eclipse OpenJ9 openj9-0.32.0)
OS: Linux 5.10.104-linuxkit amd64

 oc version
Client Version: 4.10.23

 zip
Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
This is Zip 3.0 (July 5th 2008), by Info-ZIP.

 unzip
UnZip 6.00 of 20 April 2009, by Info-ZIP. Maintained by C. Spieler. Send

 git --version
git version 2.31.1