Configure GSP
Contents
Learn how to configure GIM Stream Processor (GSP).
GSP Helm chart overrides
The GSP requires some configuration for deployment that must be made by modifying the GSP's default Helm chart. You do this by creating override entries in the GSP's values.yaml file.
Download the GSP Helm charts from the JFrog registry, using the appropriate credentials.
For information about how to download the Helm charts, see Downloading your Genesys Multicloud CX containers. To find the correct Helm chart version for your release, see Helm charts and containers for Genesys Info Mart for the Helm chart version you must download for your release. For general information about Helm chart overrides, see Overriding Helm chart values in the Genesys Multicloud CX Private Edition Guide.
At minimum, you must create entries in the values.yaml file to specify key system information, as described in the following sections.
Image registry and pull secret
Image registry
Create an entry in the GSP's values.yaml file to specify the location of the Genesys JFrog image registry. This is the repository from which Kubernetes will pull images.
The location of the Genesys JFrog image registry is defined when you set up the environment for the GSP. It is represented in the system as the docker-registry. In the GSP Helm chart, the repository is represented as image: registry, as shown below. You can optionally set a container version for the image.
image:registry— the repository from which Kubernetes will pull images (pureengage-docker-staging.jfrog.ioby default)tag— the container image version
Pull secret
When you set up your environment, you define a pull secret for Genesys JFrog image registry (docker-registry). You must include the pull secret in the GSP's values.yaml file in order for Kubernetes to be able to pull from the repository.
imagePullSecrets:docker-registry— the credentials Kubernetes will use to pull the image from the registry
Note that other services use a different syntax than this to configure the repository pull secret, as follows:
image:imagePullSecrets:- name: docker-registry- Genesys Info Mart, GIM Stream Processor, and GIM Configuration Adaptor helm charts all support advanced templating that allow the helm to create the pull secret automatically; hence the variation in syntax.
Kafka
Kafka secret
If Kafka is configured with authentication, you must configure the Kafka secret so GSP can access Kafka. The Kafka secret is provisioned in the system as kafka-secrets when you set up the environment for GSP. Configure the Kafka secret by creating a Helm chart override in the values.yaml file.
kafka:password- Credentials for accessing Kafka. This secret is created during deployment
Kafka bootstrap
To allow the Kafka service on GSP to align with the infrastructure Kafka service, make a Helm override entry with the location of the Kafka bootstrap.
kafka:bootstrap— the Kafka address to align with the infrastructure Kafka
Custom Kafka topic names
Some of the Kafka topics used by the GSP support customizing the topic name. If any topic name has been customized, ensure it is represented as a Helm chart override entry, using the kafka:topic parameter.
For a list of the Kafka topics that GSP produces and consumes, including which of those support customized naming, see Before you begin GSP deployment.
S3-compatible storage
S3 storage credentials
When you set up the environment for GSP, you provision S3-compatible object storage for GSP to use as a persistent data store. In the values.yaml file, record the credentials needed by GSP to access this storage.
gsp-s3— Credentials for accessing S3-compatible storage
Enable S3-compatible storage
When you set up your environment for the GSP, you provision S3-compatible object storage for the GSP's persistent data store. You must enable this storage with override entries in the values.yaml file.
By default, GSP is configured to use Azure Blob Storage as the persistent data store. If you have provisioned Azure Blob Storage in your deployment, modify the following entries in the values.yaml file:
job:-
storage: -
gspPrefix— the URI path prefix under which GSP savepoints, checkpoints, and high-availability data will be stored -
gcaSnapshots— the URI path under which GCA snapshot(s) will be stored
-
To enable other types of S3-compatible storage, modify the following entries in the values.yaml file:
azure:-
enabled:false
-
job:-
storage: -
gspPrefix— the bucket name where GSP savepoints, checkpoints, and high-availability data will be stored -
gcaSnapshots— the bucket name where the GCA snapshot(s) will be stored -
s3— the applicable details defined with the OBC or GCP bucket - Note: The
hostparameter is ignored.
-
OpenShift example
azure:
enabled: false
..
job:
storage:
host: gspstate{{.Values.short_location}}{{.Values.environment}}.blob.core.windows.net
#gspPrefix: wasbs://gsp-state@{{ tpl .Values.job.storage.host . }}/{{ .Release.Name }}/
gspPrefix: "s3p://gim-3f7ac1ab-03b9-445b-ba12-137d4bbc3c38/{{ .Release.Name }}/"
#gcaSnapshots: wasbs://gca@{{ tpl .Values.job.storage.host . }}/
gcaSnapshots: "s3p://gim-3f7ac1ab-03b9-445b-ba12-137d4bbc3c38/gca/"
checkpoints: '{{ tpl .Values.job.storage.gspPrefix . }}checkpoints'
savepoints: '{{ tpl .Values.job.storage.gspPrefix . }}savepoints'
highAvailability: '{{ tpl .Values.job.storage.gspPrefix . }}ha'
s3:
endpoint: "https://s3.openshift-storage.svc:443"
accessKey: "<access key>"
secretKey: "<secret key>"
pathStyleAccess: "true"GKE example
azure:
enabled: false
...
job:
storage:
host: gspstate{{.Values.short_location}}{{.Values.environment}}.blob.core.windows.net
#gspPrefix: wasbs://gsp-state@{{ tpl .Values.job.storage.host . }}/{{ .Release.Name }}/
gspPrefix: "s3p://test-example-bucket-one/{{ .Release.Name }}/"
#gcaSnapshots: wasbs://gca@{{ tpl .Values.job.storage.host . }}/
gcaSnapshots: "s3p://test-example-bucket-one/gca/"
checkpoints: '{{ tpl .Values.job.storage.gspPrefix . }}checkpoints'
savepoints: '{{ tpl .Values.job.storage.gspPrefix . }}savepoints'
highAvailability: '{{ tpl .Values.job.storage.gspPrefix . }}ha'
s3:
endpoint: "https://storage.googleapis.com:443"
accessKey: "<access Key>"
secretKey: "<secret key>"
pathStyleAccess: "true"Arbitrary UIDs (OpenShift)
If you have an OpenShift deployment and you want to use arbitrary UIDs, you must modify the security context settings in the values.yaml file. The security context settings define the privilege and access control settings for pods and containers.
In the values.yaml file, the default user and group IDs in the securityContext object are set to 500:500:500 (the genesys user), as shown below.
securityContext:
runAsNonRoot: true
runAsUser: 500
runAsGroup: 500
fsGroup: 500
containerSecurityContext: {}
To use arbitrary UIDs in your OpenShift deployment, you replace these values with null values, as in the following example.
securityContext:
runAsNonRoot: true
runAsUser: null
runAsGroup: 0
fsGroup: null
containerSecurityContext: {}
Kubernetes API
GSP uses Apache Flink for stateful stream processing, with communications handled via the Kubernetes API. To use the Kubernetes API, GSP must have the permissions shown below.
| Verbs | On Resource | API Group | Comment |
|---|---|---|---|
| get
list watch delete |
jobs | batch | GSP uses these commands during upgrade and for a pre-upgrade hook to ensure that the previous version of GSP is stopped before upgrading to the new version. |
| create
update patch get list watch delete |
configmap | general ("") | GSP uses these commands to:
|
Arbitrary UIDs (Openshift)
If you have an OpenShift deployment and you want to use arbitrary UIDs, you must modify the securityContext settings in the GSP's values.yaml file with an override entry. These settings define the privilege and access control settings for pods and containers.
In the default GSP values.yaml file, the user and group IDs are set to 500:500:500, (the genesys user), as shown below.
securityContext:
runAsNonRoot: true
runAsUser: 500
runAsGroup: 500
fsGroup: 500
containerSecurityContext: {}securityContext:
runAsNonRoot: true
runAsUser: null
runAsGroup: 0
fsGroup: null
containerSecurityContext: {}