vania-janet/multiturn-rag-retrieval-data huggingface dataset:
It also is responsible for removing a model from MinIO if the model is deleted. The system determines whether a training run completed successfully based on a flag that is stored in MinIO storage. The Master microservice must have API access to the Docker registry where the training images are stored. The image metadata that is obtained from the registry is used to correctly start the training pods.

The training pods that are started by this component are sometimes referred to as SLAD pods. SLAD stands for Statistical Learning and Discovery, which is the name of the research group that developed the language classifier that is used by the pods. The training pod names start with tr[12]?, followed by the internal vn-… ID. The training images are named nlclassifier-training or clu-training, depending on the chart version. The ${release-name}-master-config configuration map contains the JSON template for the training pods.

The ${release-name} is watson-assistant.





 Data store details 

The following sections provide more detail about how the data stores are used by the Watson Assistant service. The objective is to help you troubleshoot issues that might arise during installation or after the service is deployed and running in a data center.



 Etcd store 

Watson Assistant uses Etcd as a key-value store. Etcd is used by LiteLinks for service discovery and by the language understanding pipeline as configuration storage.

Etcd consists of five pods. The Etcd pod names follow the convention ${release-name}-etcd3-[0-9]. The Watson Assistant chart requires Etcd version 3 with enabled authorization.



 LiteLinks service discovery 

The Dialog, NLU, Master, TAS, and ED-MM microservices act as LiteLinks servers. Each LiteLinks server is registered in Etcd with its own key under the /bluegoat/litelinks/ path. Each pod stores its metadata, such as its IP address and port, into Etcd.
ceIbmenseverity: notificationSeverity,
ceId: notificationID,
ceSource: notificationsSource,
ceIbmensourceid: sourceId,
ceType: typeValue,
ceTime: date,
ceIbmenpushto: JSON.stringify(notificationFcmDevicesModel),
ceIbmenfcmbody: JSON.stringify(notificationFcmBodyModel),
ceIbmenapnsbody: JSON.stringify(notificationApnsBodyModel),
ceIbmenapnsheaders: JSON.stringify(apnsHeaders),
ceSpecversion: '1.0',
};

let res;
try {
res = await eventNotificationsService.sendNotifications(params);
console.log(JSON.stringify(res.result, null, 2));
} catch (err) {
console.warn(err);
}
Show more





 If you are using REST API 

This section contains the details about the modifications that are required for Send Notifications API. The new API has extra parameters in the request body. The required parameters for Android push notifications are as follows:

{
"specversion": "1.0",
"type": "com.acme.flightbooking.complete"
"source": "com.acme.flightbooking",
"id": "1234-1234-sdfs-234",
"ibmensourceid": "00bb34e5-b8c1-4159-af15-8bc6980c3ab2:api",
"ibmenfcmbody": "{"en_data":{"alert":" Your flight is booked"}}",
"ibmenpushto": "{"fcm_devices": ["9c75975a-3898-905d-3bd7c172"]]}",
}
echo "$REQUIRED_PKG Version is: $PKG_VER. OQSSA requires cmake 3.5 and above."
fi
fi
done
PKG_STATUS=$(yum grouplist Dev* |grep "Development Tools")
if [ "" = "$PKG_STATUS" ]
then
echo "Developement Tools is NOT installed"
fi
echo "Prerequisites verification completed"
Show more
3. Once prerequisite packages are installed and verified, execute script to build and install OQSSA:

bash build-oqssa.sh







 Making a CURL request to a quantum safe enabled endpoint 

When making a call to the the a quantum safe enabled endpoint via curl request, you will need to suse specific to ensure that the request successfully goes through. The following table contains a list of flags that are required when making a quantum safe curl request.



Table 3. Describes the flags needed to make curl requests to the Key Protect service.

 Flag Description 

 -tlsv1.3 This flag enforces that curl connects to a TLS v1.3 server. 
 --curves This flag will specify which quantum safe algorithm should be used in the 
 TLSv1.3 key exchange mechanism. If you do not specify an algorithm, the 
 flag will default to the p384_kyber768 algorithm. 



You can use the following example request to retrieve a list of keys for your Key Protect instance via a quantum safe enabled endpoint.

$ curl --tlsv1.3 --curves <qsc_algorithm> -X GET "https://qsc.<region>.kms.cloud.ibm.com/api/v2/keys" -H "accept: application/vnd.ibm.kms.key+json" -H "authorization: Bearer <IAM_token>" -H "bluemix-instance: <instance_ID>"

Replace the variables in your request according to the following table.



Table 4. Describes the variables needed to make a list keys request through a quantum safe endpoint.

 Variable Description 

 qsc_algorithm Required.
kubectl -n openshift-storage patch cephobjectstore.ceph.rook.io/ocs-storagecluster-cephobjectstore -p '{"metadata":{"finalizers":[]}}' --type=merge
kubectl -n openshift-storage patch cephobjectstoreuser.ceph.rook.io/noobaa-ceph-objectstore-user -p '{"metadata":{"finalizers":[]}}' --type=merge
kubectl -n openshift-storage patch cephobjectstoreuser.ceph.rook.io/ocs-storagecluster-cephobjectstoreuser -p '{"metadata":{"finalizers":[]}}' --type=merge
kubectl -n openshift-storage patch noobaa/noobaa -p '{"metadata":{"finalizers":[]}}' --type=merge
kubectl -n openshift-storage patch backingstores.noobaa.io/noobaa-default-backing-store -p '{"metadata":{"finalizers":[]}}' --type=merge
kubectl -n openshift-storage patch bucketclasses.noobaa.io/noobaa-default-bucket-class -p '{"metadata":{"finalizers":[]}}' --type=merge
kubectl -n openshift-storage patch storagecluster.ocs.openshift.io/ocs-storagecluster -p '{"metadata":{"finalizers":[]}}' --type=merge
sleep 20
oc delete pods -n openshift-storage --all --force --grace-period=0
oc delete ns local-storage --wait=false
sleep 20
If you still see unacceptable performance, contact support, see [Getting help and support for Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-help-and-support).





 How often are the security notices updated? 

Security notices for Vulnerability Advisor are loaded from the vendors' operating system sites approximately every 12 hours.





 Why can I see a vulnerability in Vulnerability Advisor v4 but not in v3? 

Some vulnerabilities are picked up earlier by Vulnerability Advisor version 4 than by version 3 because version 4 uses a different architecture and a different scanning engine.

Vulnerability Advisor version 3 is deprecated from 19 June 2023. For more information about how to update to version 4, see [Update Vulnerability Advisor to version 4 by 19 June 2023](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_notices_va_v4&interface=ui).





 Which version of a package is installed in my image? 

To determine the version of a package that is installed in your image, use the relevant package manager command for your operating system.



 Alpine package manager commands 

On Alpine, to determine the version of a package that is installed in your image, you can use the following commands, where <package_name> is the name of your package.



* To list the metadata for a specific installed package, run the following command:

apk info <package_name>
* To list all installed packages and their versions, run the following command:

apk list







 Debian and Ubuntu package manager commands 

On Debian and Ubuntu, to determine the version of a package that is installed in your image, you can use the following commands, where <package_name> is the name of your package.



* To list the metadata for a specific installed package, run either of the following commands:

apt show <package_name>

dpkg-query -l <package_name>
* To list all installed packages and their versions, run either of the following commands:

apt list

dpkg-query -W







 Red Hat and CentOS package manager commands
* 198.18.0.0 - 198.19.255.255



: Note that the pod and service subnets can't overlap. The pod subnet is in the 172.16.0.0/16 range by default. This value can't be set to the value of the related location's pod-subnet or service-subnet.

--pod-network-interface-selection METHOD
: Optional. The method for selecting the node network interface for the internal pod network. The available methods are can-reach and interface. This option can be used only if you also enable Red Hat CoreOS with the --operating-system option.



* To provide a direct URL or IP address, specify can-reach=<url> or can-reach=<ip_address>. If the network interface can reach the provided URL or IP address, this option is used. For example, use can-reach=www.exampleurl.com for specifying a URL and can-reach=172.19.0.0 for specifying an IP address.
* To choose an interface with a Regex string, specify interface=<regex_string>; for example, interface=eth.



--provider INFRASTRUCTURE_PROVIDER
: Optional. The name of the infrastructure provider to create the Satellite location in. Accepted values are aws, azure, gcp. If you include this option, you must also include the --provider-credential option.

--provider-region PROVIDER_REGION
: Optional. The name of the region in the infrastructure provider where you plan to create all the hosts for the Satellite location, such as us-east-1 in AWS. Consult your infrastructure provider for the region name. If you include this option, you must also include the --provider option.

--provider-credential PATH_TO_PROVIDER_CREDENTIAL
: Optional. The path to a JSON file on your local machine that has the credentials of the infrastructure provider for the Satellite location. The credential format is provider-specific.
PodFailureThresholdPercent When the resource type is POD, enter the threshold for the percentage of pods on a worker node that can be in a [NotReady](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/define-readiness-probes) state. This percentage is based on the total number of pods that are scheduled to a worker node. When a check determines that the percentage of unhealthy pods is greater than the threshold, the check counts as one failure. 
 CorrectiveAction Enter the action to run when the failure threshold is met. A corrective action runs only while no other workers are being repaired and when this worker node is not in a cool-off period from a previous action. <br>REBOOT: Reboots the worker node. <br>RELOAD: Reloads all the necessary configurations for the worker node from a clean OS. 
 CooloffSeconds Enter the number of seconds Autorecovery must wait to issue another corrective action for a node that was already issued a corrective action. The cool off period starts at the time a corrective action is issued. 
 IntervalSeconds Enter the number of seconds between consecutive checks. For example, if the value is 180, Autorecovery runs the check on each node every 3 minutes. 
 TimeoutSeconds Enter the maximum number of seconds that a check call to the database takes before Autorecovery terminates the call operation. The value for TimeoutSeconds must be less than the value for IntervalSeconds. 
 Port When the check type is HTTP, enter the port that the HTTP server must bind to on the worker nodes. This port must be exposed on the IP of every worker node in the cluster. Autorecovery requires a constant port number across all nodes for checking servers. Use [daemon sets](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) when you deploy a custom server into a cluster. 
 ExpectedStatus When the check type is HTTP, enter the HTTP server status that you expect to be returned from the check.
"DoNotConnectToWindowsUpdateInternetLocations"=dword:00000001

[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU]
"AUOptions"=dword:00000005
"NoAutoRebootWithLoggedonUsers"=dword:00000001
"NoAutoUpdate"=dword:00000000
"RebootReLaunchTimeout"=dword:000000f0
"RebootReLaunchTimeoutEnabled"=dword:00000001
"RebootWarningTimeout"=dword:0000000a
"RebootWarningTimeoutEnabled"=dword:00000001
"RescheduleWaitTime"=dword:0000000a
"RescheduleWaitTimeEnabled"=dword:00000001
"ScheduledInstallDay"=dword:00000000
"ScheduledInstallTime"=dword:00000002
"UseWUServer"=dword:00000001
Show more
You don't want pods in other namespaces, such as kube-system, ibm-system, or default, to access your on-premises network. To limit the VPN traffic to only my-secure-namespace, you can create Calico global network policies.

Before you use this solution, review the following considerations and limitations.



* You don't need to deploy the strongSwan Helm chart into the specified namespace. The strongSwan VPN pod and the routes daemon set can be deployed into kube-system or any other namespace. If the strongSwan VPN is not deployed into the specified namespace, then the vpn-strongswan-ping-remote-ip-1 Helm test fails. This failure is expected and acceptable. The test pings the remote.privateIPtoPing private IP address of the on-premises VPN gateway from a pod which is not in the namespace that has direct access to the remote subnet. However, the VPN pod is still able to forward traffic to pods in the namespaces that do have routes to the remote subnet, and traffic can still flow correctly. The VPN state is still ESTABLISHED and pods in the specified namespace can connect over the VPN.
* The Calico global network policies in the following steps don't prevent Kubernetes pods that use host networking from sending and receiving data over the VPN. When a pod is configured with host networking, the app running in the pod can listen on the network interfaces of the worker node that it is on. These host networking pods can exist in any namespace. To determine which pods have host networking, run oc get pods --all-namespaces -o wide and look for any pods that don't have a 172.30.0.0/16 pod IP address. If you want to prevent host networking pods from sending and receiving data over the VPN, you can set the following options in your values.yaml deployment file: local.subnet: 172.30.0.0/16 and enablePodSNAT: false. These configuration settings expose all the Kubernetes pods over the VPN connection to the remote network. However, only the pods that are located in the specified secure namespace are reachable over the VPN.
To block unnecessary access, you can apply a policy such as the following, which allows all ingress to TCP and UDP port 53 so that pods can access the CoreDNS functionality. However, it blocks all other ingress, such as any attempts to gather metrics from the CoreDNS pods, except from pods or services in namespaces that have the coredns-metrics-policy: allow label, or from pods in the kube-system namespace that have the coredns-metrics-policy: allow label.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: coredns-metrics
namespace: kube-system
spec:
ingress:
- from:
- namespaceSelector:
matchLabels:
coredns-metrics-policy: allow
- podSelector:
matchLabels:
coredns-metrics-policy: allow
- ports:
- port: 53
protocol: TCP
- port: 53
protocol: UDP
podSelector:
matchLabels:
k8s-app: kube-dns
policyTypes:
- Ingress
Show more

For more information about how Kubernetes network policies control pod-to-pod traffic and for more example policies, see the [Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/network-policies/).



 Isolate app services within a namespace 

The following scenario demonstrates how to manage traffic between app microservices within one namespace.

An Accounts team deploys multiple app services in one namespace, but they need isolation to permit only necessary communication between the microservices over the public network. For the app Srv1, the team has front end, back end, and database services. They label each service with the app: Srv1 label and the tier: frontend, tier: backend, or tier: db label.

Zoom

![Use a network policy to manage cross-namepspace traffic.]
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. 
 privileged Allows access to all privileged and host features and the ability to run as any user, any group, any fsGroup setting, and with any SELinux context.<br><br>Important: Grant this SCC for only cluster administration that requires the most access possible. 
 restricted Denies access to all host features and requires that pods are run with a UID and SELinux context that are allocated to the namespace. This is the most restrictive SCC, and it is used by default for authenticated users. 
 hostnetwork-v2 Similar to the hostnetwork SCC, but modified to minimize differences from the Pod Security Standards Restricted profile. 
 nonroot-v2 Similar to the nonroot SCC, but modified to minimize differences from the Pod Security Standards Restricted profile. 
 restricted-v2 Similar to the restricted SCC, but modified to satisfy the Pod Security Standards Restricted profile. 







 Default IBM security context constraints 

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

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



Default IBM security context constraints

 SCC name Description 

 ibm-anyuid-hostaccess-scc Allows pods to run with any UID and GID, any volume, and full access to the host.<br><br>Important: Grant this SCC for only pods that require full access to the host and network. 
 ibm-anyuid-hostpath-scc Allows pods to run with any UID and GID and any volume, including the host path.<br><br>Important: Grant this SCC for only pods that require access to hostPath volumes.
sttRuntime:
skipAudioAndResultLogging: "false" If true, disables storage and logging of user data
sttAMPatcher:
skipAudioAndResultLogging: "false" If true, disables storage and logging of user data
ttsRuntime:
skipAudioAndResultLogging: "false" If true, disables storage and logging of user data

If you already set these properties in your custom resource to change the default value of false to true, you need to edit your custom resource. You must manually change the names of the properties to the new values and save the updated custom resource. For more information, see [Installing Watson Text to Speech](https://www.ibm.com/docs/en/cloud-paks/cp-data/4.0?topic=speech-installing-watson-text).

Important: Changes to properties of PostgreSQL secrets object
: Important: When you install the Speech services, an object that contains a randomly generated password for the PostgreSQL datastore is created by default. You can choose instead to specify the password manually. If you do, the properties of the YAML file for the secrets object have changed. For more information, see the topic about managing your datastores in [Administering Watson Text to Speech](https://www.ibm.com/docs/en/cloud-paks/cp-data/4.0?topic=speech-administering-watson-text).

Important: PostgreSQL pods do not start with EnterpriseDB version 1.10 operator
: Important: With Text to Speech for IBM Cloud Pak for Data version 4.0.3, PostgreSQL pods based on the EnterpriseDB version 1.10 operator can fail to start. This prevents the Speech services from starting. A workaround exists for this problem. If your Speech services fail to start, see [PostgreSQL pods do not start with EnterpriseDB version 1.10 operator](https://www.ibm.com/support/pages/node/6525340) for information about diagnosing and resolving the problem.
Why can't I add non-root user access to persistent storage? 

Classic infrastructure

 What’s happening 

After you [add non-root user access to persistent storage](https://cloud.ibm.com/docs/openshift?topic=openshift-nonroot) or deploy a Helm chart with a non-root user ID specified, the user can't write to the mounted storage.

 Why it’s happening 

Your app deployment or Helm chart configuration specifies the [security context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) for the pod's fsGroup (group ID) and runAsUser (user ID). Generally, a pod's default security context sets [runAsNonRoot](https://kubernetes.io/docs/concepts/security/pod-security-policy/) so that the pod can't run as the root user. Because the fsGroup setting is not designed for shared storage such as NFS file storage, the fsGroup setting is not supported, and the runAsUser setting is automatically set to 2020. These default settings don't allow other non-root users to write to the mounted storage.

 How to fix it 

To allow a non-root user read and write access to a file storage device, you must allocate a [supplemental group ID](https://kubernetes.io/docs/concepts/security/pod-security-policy/) in a storage class, refer to this storage class in the PVC, and set the pod's security context with a runAsUser value that is automatically added to the supplemental group ID. When you grant the supplemental group ID read and write access to the file storage, any non-root user that belongs to the group ID, including your pod, is granted access to the file storage.

You can use one of the provided [gid storage classes](https://cloud.ibm.com/docs/openshift?topic=openshift-file_storagefile_storageclass_reference) or create a custom storage class to define your own supplemental group ID.
if [! "$1" = "iam" ]] && [! "$1" = "pod-identity" ]]; then
echo "Provide a valid auth-type"
usage; exit 1
fi

IBMCLOUD_AUTHTYPE=$1
SECRET=$2
}

usage - prints the usage for execution of script
usage() {
echo "USAGE:
bash generate-secret.sh <auth-type> <apikey/profile-id>
auth-type: auth-type should be either iam or pod-identity. Provide iam to use api key, pod-identity to use trusted profile"
}

main
main() {

validate_options "$@"

auth_type="IBMCLOUD_AUTHTYPE=$IBMCLOUD_AUTHTYPE"

secret=

if [ "$IBMCLOUD_AUTHTYPE" == "iam" ]]; then
secret="IBMCLOUD_APIKEY=$SECRET"
else
secret="IBMCLOUD_PROFILEID=$SECRET"
fi

encodedValue=$(echo -e "$auth_typen$secret" | base64)
on certain os, base64 encoding introduces newline, removing the same here.
encodedValue=${encodedValue//$'n'/}

fetch the controller pod name
controllerPodName=$(kubectl get pods -n kube-system | grep ibm-vpc-block-csi-controller | awk '{print $1}')
error "$(date +"%b %d %G %H:%M:%S"): Unable to fetch controller pod."
if [ "$controllerPodName" == "" ]]; then
echo "$(date +"%b %d %G %H:%M:%S"): VPC Block CSI Driver addon is not enabled"
exit 1
fi

echo "apiVersion: v1
data:
ibm-credentials.env: $encodedValue