Difference between revisions of "PEC-REP/Current/GCXIPEGuide/PlanningRAA"

From Genesys Documentation
Jump to: navigation, search
 
(3 intermediate revisions by 2 users not shown)
Line 3: Line 3:
 
|Context=Find out what to do before deploying Reporting and Analytics Aggregates (RAA).
 
|Context=Find out what to do before deploying Reporting and Analytics Aggregates (RAA).
 
|LimitationsStatus=No
 
|LimitationsStatus=No
|LimitationsText=The RAA container works with the {{Link-AnywhereElse|product=PEC-REP|version=Current|manual=GIMPEGuide|display text=Genesys Info Mart}} database; deploy RAA only after you have deployed Genesys Info Mart. The Genesys Info Mart database schema must correspond to a compatible Genesys Info Mart version. Execute the following command to discover the required Genesys Info Mart release:
+
|LimitationsText=The RAA container works with the {{Link-AnywhereElse|product=PEC-REP|version=Current|manual=GIMPEGuide|display text=Genesys Info Mart}} database; deploy RAA only after you have deployed Genesys Info Mart.  
 +
 
 +
The Genesys Info Mart database schema must correspond to a compatible Genesys Info Mart version. Execute the following command to discover the required Genesys Info Mart release:
 
<source lang="bash">docker run -it --entrypoint /bin/java gcxi/raa:<IMAGE_VERSION> -jar GIMAgg.jar -version</source>
 
<source lang="bash">docker run -it --entrypoint /bin/java gcxi/raa:<IMAGE_VERSION> -jar GIMAgg.jar -version</source>
 
RAA container runs RAA on Java 11, and is supplied with the following of JDBC drivers:
 
RAA container runs RAA on Java 11, and is supplied with the following of JDBC drivers:
Line 11: Line 13:
 
*Oracle Database 21c (21.1) JDBC Driver
 
*Oracle Database 21c (21.1) JDBC Driver
  
You can override the JDBC driver by copying the driver file to '''lib\jdbc_driver_<RDBMS>''' (or by making a link) in a work directory. See [https://docs.genesys.com/Documentation/RAA/9.0.0/Dep/PostInstall#JDBCDriverForRAA JDBC driver for RAA] for details.
+
Genesys recommends that you verify whether the provided driver is compatible with your database, and if it is not, you can override the JDBC driver by copying an updated driver file to the folder '''lib\jdbc_driver_<RDBMS>''' within the mounted config volume, or by creating a co-named link within the folder '''lib\jdbc_driver_<RDBMS>''', which points to a driver file stored on another volume (where '''&lt;RDBMS&gt;''' is the RDBMS used in your environment). This is possible because RAA is launched in a config folder, which is mounted in a container.  
 +
 
 
|HelmStatus=No
 
|HelmStatus=No
|HelmText=For general information about downloading containers, see: {{SuiteLevelLink|helmchart}}.
+
|HelmText=
 
 
 
<span lang="EN-CA">To learn what Helm chart version you must download for your release, see</span> {{Link-AnywhereElse|product=ReleaseNotes|version=Current|manual=GenesysEngage-cloud|topic=GCXIHelm|display text=Helm charts and containers for Genesys Customer Experience Insights}}.
 
<span lang="EN-CA">To learn what Helm chart version you must download for your release, see</span> {{Link-AnywhereElse|product=ReleaseNotes|version=Current|manual=GenesysEngage-cloud|topic=GCXIHelm|display text=Helm charts and containers for Genesys Customer Experience Insights}}.
 
+
You can download the gcxi helm charts from the following repository:<source lang="bash">https://pureengage.jfrog.io/ui/packages/helm:%2F%2Fgcxi-raa</source>
==Init containers==
+
For more information about downloading containers, see: {{SuiteLevelLink|helmchart}}.
The RAA Helm chart includes two explicit init containers:
+
|ThirdPartyStatus=No
 
+
|ThirdPartyText=For information about setting up your Genesys Multicloud CX private edition platform, including Kubernetes, Helm, and other prerequisites, see {{SuiteLevelLink|softwarereq}}.
*'''configDelivery''' -- this container delivers required XML configuration and *.SS files in the RAA working directory. Those files must be available in a GZIP archive, encoded as base64, which must be passed using the Helm install/update option '''--set-file raa.deployment.configTar=config.tar.gz.b64'''. Default '''conf.xml''' and '''user-data-map.ss''' are supplied with the Helm chart. If a GZIP archive is not specified by the '''--set-file''' option, the init container copies them into the working directory (unless they are already present). <br />The configDelivery init container is optional, and is disabled by default; when it is disabled, you can create RAA configuration files in the mounted config volume. The configDelivery init container makes sense when access to the mounted working directory is restricted for any reason -- often for security reasons, or due to use of ephemeral storage for the configuration volume.<br />You must specify a container name value to enable configDelivery container:
+
{{AnchorDiv|JDBCDrivers}}
*:'''myvalues.yaml'''
 
*:<source lang="bash">raa:
 
  ...
 
  statefulset:
 
  ...
 
    containers:
 
    ...
 
      configDelivery:
 
        name: "{{ $.Chart.Name }}-conf-delivery"</source>
 
 
 
*'''testRun''' -- this container executes all the aggregations on an empty time range. This helps to quickly detect configuration and customization problems -- SQL execution (even on empty data) checks the presence of involved tables and columns. The testRun init container is optional, and is enabled by default. To disable the container, set testRun: with no value in the container section of your myvalues.yaml:
 
*:'''myvalues.yaml'''
 
*:<source lang="bash">raa:
 
  ...
 
  statefulset:
 
  ...
 
    containers:
 
    ...
 
      testRun:
 
        name: "{{ $.Chart.Name }}-test-run"</source>
 
 
 
==Pod containers==
 
RAA has two execution containers:
 
 
 
*'''aggregation''' -- this container does the aggregation work. It is a required container, and only the container name is specified in the '''values.yaml''' file:
 
*:'''myvalues.yaml'''
 
*:
 
<source lang="bash">raa:
 
  ...
 
  statefulset:
 
  ...
 
    containers:
 
      aggregation:
 
        name: "{{ $.Chart.Name }}"
 
      ...</source>
 
 
 
*'''monitor''' -- this container allows execution of the RAA tool from file. Use this function when the kubeclt exececutable is not available in your environment (for example, for security reasons). The monitor container also exposes two ports to enable scraping of aggregation metrics and health metric by Prometheus, or other monitoring tools. Monitor container is optional and disabled by default. Set values for '''monitor:''' as follows:
 
*:'''myvalues.yaml'''
 
*:<source lang="bash">raa:
 
  ...
 
  statefulset:
 
  ...
 
    containers:
 
    ...
 
      monitor:
 
        name: "{{ $.Chart.Name }}-monitor"
 
 
        toolcmd:
 
          # interval of checking for a new file with command
 
          intervalSec: "20"
 
 
        metrics:
 
          portName: "metrics"
 
          containerPort: "9100"
 
 
        health:
 
          portName: "health"
 
          containerPort: "9101"
 
      ...</source>
 
 
 
==Test containers==
 
RAA includes two test containers for the Helm test command. They bust be executed in the following order:
 
 
 
#'''testRunCheck''' -- this container waits for execution of the testRun init container, and returns a result of test execution. The test is optional, and enabled by default. Enable it only when you plan to run the testRun init container; otherwise, disable it by setting testRunCheck: with no value in the testPod section of your '''values.yaml''' file, as follows:
 
#:'''myvalues.yaml'''
 
#:<source lang="bash">raa:
 
  ...
 
  testPods:
 
 
    testRunCheck:
 
 
      name: "{{ tpl .Values.raa.serviceName . }}-test-run-check"
 
 
      container:
 
        name: "{{ $.Chart.Name }}-test-run-check"
 
 
      labels: {}
 
 
      annotations:
 
        "helm.sh/hook-weight": "100"
 
        "helm.sh/hook": "test-success"
 
        "helm.sh/hook-delete-policy": "before-hook-creation"
 
      ...</source>
 
#healthChek -- this container executes and returns status of healthCheck, and prints the content of current configuration files and health files to standard output. The test is optional and enabled by default. To disable this test, set healthCheck: with no value in the testPod section of your '''values.yaml''' file, as follows:
 
#:'''myvalues.yaml'''
 
#:<source lang="bash">raa:
 
  ...
 
  testPods:
 
    ...
 
    healthCheck:
 
      name: "{{ tpl .Values.raa.serviceName . }}-health-check"
 
 
      container:
 
        name: "{{ $.Chart.Name }}-health-check"
 
 
      labels: {}
 
 
      annotations:
 
        "helm.sh/hook-weight": "200"
 
        "helm.sh/hook": "test-success"
 
        "helm.sh/hook-delete-policy": "before-hook-creation"
 
      ...</source>
 
|ThirdPartyStatus=Yes
 
|ThirdPartyText={{Notices|Notice=PEComingSoon}}
 
 
 
{{AnchorDiv|StorageRequirements}}
 
 
|StorageStatus=No
 
|StorageStatus=No
|StorageText====GIM secret volume===
+
|StorageText=This section describes the storage requirements for various volumes.
RAA mounts as a volume secret with Genesys Info Mart connections details when <code class="yml variable">raa.env.GCXI_GIM_DB__JSON</code> is not specified.  
+
===GIM secret volume===
 +
In scenarios where '''raa.env.GCXI_GIM_DB__JSON''' is not specified, RAA mounts this volume to provide GIM connections details.
  
You can declare Genesys Info Mart database connection details as a Kubernetes secret, as follows:
+
#Declare GIM database connection details as a Kubernetes secret in '''gimsecret.yaml''':
 
+
#:<source lang="bash">apiVersion: v1
'''gimsecret.yaml'''
 
<source lang="bash">apiVersion: v1
 
 
kind: Secret
 
kind: Secret
 
metadata:
 
metadata:
Line 141: Line 36:
 
type: kubernetes.io/service-account-token
 
type: kubernetes.io/service-account-token
 
data:
 
data:
   json_credentials: eyJqZGJjX3VybCI6ImpkYmM6cG9zdGdyZXNxbDovLzxob3N0Pjo1NDMyLzxnaW1fZGF0YWJhc2U+IiwgImRiX3VzZXJuYW1lIjoiPHVzZXI+IiwgImRiX3Bhc3N3b3JkIjoiPHBhc3N3b3JkPiJ9Cg==
+
   json_credentials: eyJqZGJjX3VybCI6ImpkYmM6cG9zdGdyZXNxbDovLzxob3N0Pjo1NDMyLzxnaW1fZGF0YWJhc2U+IiwgImRiX3VzZXJuYW1lIjoiPHVzZXI+IiwgImRiX3Bhc3N3b3JkIjoiPHBhc3N3b3JkPiJ9Cg==</source>
</source>
+
#Reference '''gimsecret.yaml''' in '''values.yaml''':
And reference the secret in the '''values.yaml''', as follows:
+
#:<source lang="bash">raa
 
 
'''myvalues.yaml'''
 
<source lang="bash">raa
 
 
   ...
 
   ...
 
   volumes:
 
   volumes:
Line 155: Line 47:
 
       jsonFile: "json_credentials"
 
       jsonFile: "json_credentials"
 
   ...</source>
 
   ...</source>
Alternatively,  you can mount a CSI secret using secretProviderClass, as follows:
 
  
'''myvalues.yaml'''
+
Alternatively, you can mount the CSI secret using '''secretProviderClass''',  in '''values.yaml''':<source lang="bash">raa
<source lang="bash">raa
 
 
   ...
 
   ...
 
   volumes:
 
   volumes:
Line 169: Line 59:
 
{{AnchorDiv|StorageRequirementsConfig}}
 
{{AnchorDiv|StorageRequirementsConfig}}
 
===Config volume===
 
===Config volume===
RAA mounts a config volume folder inside the container, as '''/genesys/raa_config'''; this folder is the RAA working directory. At startup, RAA attempts to read the following files from /genesys/raa_config:
+
RAA mounts a config volume inside the container, as the folder '''/genesys/raa_config'''. The folder is treated as a work directory, RAA reads the following files from it during startup:
 
 
*custom '''*.ss''' files &mdash; see [https://docs.genesys.com/Documentation/RAA/9.0.0/UG/CustomAgg How Do I Customize Queries and Hierarchies?] for details.
 
*JDBC driver from '''lib/jdbc_driver_&lt;RDBMS&gt;''' &mdash; see [https://docs.genesys.com/Documentation/RAA/9.0.0/Dep/PostInstall#JDBCDriverForRAA Procedure: Configuring the JDBC Driver for RAA] for details.
 
*'''conf.xml''' &mdash; This file must be present in the working folder, or aggregation cannot start.
 
*:The default conf.xml (provided with Helm chart) has the following content:
 
*:<source lang="bash"><CfgOptions>
 
<Application>
 
  <i id="agg">
 
  <i k="sub-hour-interval" v="30min"/>
 
  </i>
 
  <i id="agg-feature">
 
  <i k="materialize-subhour-in-db" v="true"/>
 
  <i k="enable-available-features" v="true"/>
 
  </i>
 
  <i id="cfgApplication">
 
  <i k="CFGAPP_NAME" v="RAA" />
 
  </i>
 
</Application>
 
</CfgOptions>
 
</source>
 
  
Usually RAA does not create any files here at runtime, so the volume does not requires a superfast storage class.  
+
*'''conf.xml''', which contains application-level config settings.
Size limit is set to 50M by default. The storage class and size limit can be specified in values, as follows:
+
*custom '''*.ss''' files.
 +
*JDBC driver, from the folder '''lib/jdbc_driver_<RDBMS>'''.
  
'''myvalues.yaml'''
+
RAA does not normally create any files in '''/genesys/raa_config''' at runtime, so the volume does not require a fast storage class. By default, the size limit is set to 50 MB. You can specify the storage class and size limit in '''values.yaml''':<source lang="bash">raa
<source lang="bash">raa
 
 
   ...
 
   ...
 
   volumes:
 
   volumes:
Line 201: Line 71:
 
     config:
 
     config:
 
       capacity: 50Mi
 
       capacity: 50Mi
       storageClassName: "<vendor storage class>"
+
       storageClassName: "<vendor storage class>"</source>
    ...</source>
 
RAA Helm chart creates Persistent Volume Claim. It can also optionally create a Persistent Volume (when <code class="yml variable">raa.volumes.config.pv</code> is specified). The following example illustrates how Persistent Volume is declared in the Helm chart:
 
 
 
'''raa-config-volume.yaml'''
 
<source lang="bash">{{- with .Values.raa.volumes.config.pv }}
 
apiVersion: v1
 
kind: PersistentVolume
 
metadata:
 
  name: "{{ tpl .name $ }}"
 
  {{- if or ($.Values.raa.labels) (.labels) }}
 
  labels:
 
  {{- with $.Values.raa.labels }}
 
    {{- range $key, $value := . }}
 
    {{ $key }}: "{{ tpl $value $ }}"
 
    {{- end }}
 
  {{- end }}
 
  {{- with .labels }}
 
    {{- range $key, $value := . }}
 
    {{ $key }}: "{{ tpl $value $ }}"
 
    {{- end }}
 
  {{- end }}
 
  {{- end }}
 
 
  {{- if or ($.Values.raa.annotations) (.annotations) }}
 
  annotations:
 
  {{- with $.Values.raa.annotations }}
 
    {{- range $key, $value := . }}
 
    {{ $key }}: "{{ tpl $value $ }}"
 
    {{- end }}
 
  {{- end }}
 
  {{- with .annotations }}
 
    {{- range $key, $value := . }}
 
    {{ $key }}: "{{ tpl $value $ }}"
 
    {{- end }}
 
  {{- end }}
 
  {{- end }}
 
 
spec:
 
  accessModes:
 
    - ReadWriteMany
 
  {{- with $.Values.raa.volumes.config }}
 
  capacity:
 
    storage: "{{ .capacity }}"
 
    {{- with .storageClassName }}
 
  storageClassName: "{{ . }}"
 
    {{- end }}
 
    {{- with .pv.vendorSpec}}
 
  {{- toYaml . | nindent 2 }}
 
    {{- end}}
 
  {{- end }}
 
{{- end }}</source>
 
It is enough to define <code class="yml variable">Values.raa.volumes.config.storageClassName</code> and a vendor specific part of Persistent Volume (<code class="yml variable">raa.volumes.config.pv.vendorSpec)</code> in values file:
 
 
 
'''myvalues.yaml'''
 
<source lang="bash">raa
 
  ...
 
  volumes:
 
 
     ...
 
     ...
    config:
+
RAA helm chart creates a Persistent Volume Claim (PVC). You can define a Persistent Volume (PV) separately using the '''gcxi-raa''' chart, and bind such a volume to the PVC by specifying the volume name in the '''raa.volumes.config.pvc.volumeName''' value, in '''values.yaml''':<source lang="bash">
      storageClassName: "hostpath"
+
raa
      pv:
 
        vendorSpec:
 
          hostPath:
 
            type: Directory
 
            # path for conf.xml, *.ss files and JDBC driver when default is not suitable
 
            path: "/usr/local/genesys/RAA/config/"   
 
      ...</source>
 
Alternatively, you can define Persistent Volume separately by defining the name must in '''values.yaml''' using the <code class="yml variable">raa.volumes.config.pvc.volumeName</code> for binding to Persistent Volume Claim:
 
 
 
'''myvalues.yaml'''
 
<source lang="bash">raa
 
 
   ...
 
   ...
 
   volumes:
 
   volumes:
 
     ...
 
     ...
 
     config:
 
     config:
      pv: {}
 
 
       pvc:
 
       pvc:
 
         volumeName: "my_raa_config_volume"
 
         volumeName: "my_raa_config_volume"
 
     ...</source>
 
     ...</source>
 
Optionally, you can also map ephemeral storage.
 
 
{{AnchorDiv|StorageRequirementsHealth}}
 
{{AnchorDiv|StorageRequirementsHealth}}
 
===Health volume===
 
===Health volume===
RAA uses health volume for the following purposes:
+
RAA uses the Health volume to store:
  
*placing actual health files (see [https://docs.genesys.com/Documentation/RAA/latest/UG/AggProc#Checking_the_health_of_the_aggregate_process Checking the health of the aggregate process] for details)
+
*Health files.
*place for prometheus file containing metrics for 2-3 scrape intervals behind
+
*Prometheus file containing metrics for the most recent 2-3 scrape intervals.
*results of recent '''testRun''' init container execution
+
*Results of the most recent '''testRun init''' container execution.
  
Size limit is set to 50MB by default. Periodic interaction with the volume at runtime is expected, so Genesys does not recommended the use of very slow storage class for this volume.
+
By default, the volume is limited to 50MB. RAA periodically interacts with the volume at runtime, so Genesys does not recommend a slow storage class for this volume. You can specify the storage class and size limit in '''values.yaml''':<source lang="bash">raa
 
 
'''myvalues.yaml'''
 
 
 
<source lang="bash">raa
 
 
   ...
 
   ...
 
   volumes:
 
   volumes:
Line 302: Line 97:
 
       capacity: 50Mi
 
       capacity: 50Mi
 
       storageClassName: "<vendor storage class>"
 
       storageClassName: "<vendor storage class>"
   ...</source>
+
   ...</source>RAA helm chart creates a PVC. You can define a PV separately using the '''gcxi-raa''' chart, and bind such a volume to the PVC by specifying the volume name in the '''raa.volumes.health.pvc.volumeName''' value, in '''values.yaml''':<source lang="bash">raa
The RAA Helm chart creates a Persistent Volume Claim. It can also optionally create a Persistent Volume (when <code class="yml variable">raa.volumes.health.pv</code> is specified). See how Persistent Volume is declared in the Helm chart:
 
 
 
'''raa-config-volume.yaml'''
 
<source lang="bash">{{- with .Values.raa.volumes.health.pv }}
 
apiVersion: v1
 
kind: PersistentVolume
 
metadata:
 
  name: "{{ tpl .name $ }}"
 
  {{- if or ($.Values.raa.labels) (.labels) }}
 
  labels:
 
  {{- with $.Values.raa.labels }}
 
    {{- range $key, $value := . }}
 
    {{ $key }}: "{{ tpl $value $ }}"
 
    {{- end }}
 
  {{- end }}
 
  {{- with .labels }}
 
    {{- range $key, $value := . }}
 
    {{ $key }}: "{{ tpl $value $ }}"
 
    {{- end }}
 
  {{- end }}
 
  {{- end }}
 
 
  {{- if or ($.Values.raa.annotations) (.annotations) }}
 
  annotations:
 
  {{- with $.Values.raa.annotations }}
 
    {{- range $key, $value := . }}
 
    {{ $key }}: "{{ tpl $value $ }}"
 
    {{- end }}
 
  {{- end }}
 
  {{- with .annotations }}
 
    {{- range $key, $value := . }}
 
    {{ $key }}: "{{ tpl $value $ }}"
 
    {{- end }}
 
  {{- end }}
 
  {{- end }}
 
 
spec:
 
  accessModes:
 
    - ReadWriteMany
 
  {{- with $.Values.raa.volumes.health }}
 
  capacity:
 
    storage: "{{ .capacity }}"
 
    {{- with .storageClassName }}
 
  storageClassName: "{{ . }}"
 
    {{- end }}
 
    {{- with .pv.vendorSpec}}
 
  {{- toYaml . | nindent 2 }}
 
    {{- end}}
 
  {{- end }}
 
{{- end }}</source>
 
It is enough to define <code class="yml variable">Values.raa.volumes.health.storageClassName</code> and a vendor specific part of Persistent Volume (<code class="yml variable">raa.volumes.health.pv.vendorSpec)</code> in values file:
 
 
 
'''myvalues.yaml'''
 
<source lang="bash">raa
 
 
   ...
 
   ...
 
   volumes:
 
   volumes:
 
     ...
 
     ...
 
     health:
 
     health:
      storageClassName: "hostpath"
 
      pv:
 
        vendorSpec:
 
          hostPath:
 
            type: Directory
 
            path: "/usr/local/genesys/RAA/health/"   
 
      ...</source>
 
Alternatively, you can separatly define a Persistent Volume; define its name in '''values.yaml''', using the <code class="yml variable">raa.volumes.health.pvc.volumeName</code> for binding to Persistent Volume Claim:
 
 
'''myvalues.yaml'''
 
<source lang="bash">raa
 
  ...
 
  volumes:
 
    ...
 
    config:
 
      pv: {}
 
 
       pvc:
 
       pvc:
 
         volumeName: "my_raa_helath_volume"
 
         volumeName: "my_raa_helath_volume"
     ...</source>
+
     ...</source><br />
You can also map an ephemeral storage.  
 
 
|NetworkStatus=No
 
|NetworkStatus=No
 
|NetworkText=RAA interacts only with the Genesys Info Mart database.   
 
|NetworkText=RAA interacts only with the Genesys Info Mart database.   
Line 399: Line 123:
 
|GDPRStatus=No
 
|GDPRStatus=No
 
|GDPRText=Not applicable.
 
|GDPRText=Not applicable.
|PEPageType=bf21dc7c-597d-4bbe-8df2-a2a64bd3f167
 
 
}}
 
}}

Latest revision as of 18:00, May 10, 2022

This topic is part of the manual Genesys Customer Experience Insights Private Edition Guide for version Current of Reporting.

Find out what to do before deploying Reporting and Analytics Aggregates (RAA).

Limitations and assumptions

The RAA container works with the Genesys Info Mart database; deploy RAA only after you have deployed Genesys Info Mart.

The Genesys Info Mart database schema must correspond to a compatible Genesys Info Mart version. Execute the following command to discover the required Genesys Info Mart release:

docker run -it --entrypoint /bin/java gcxi/raa:<IMAGE_VERSION> -jar GIMAgg.jar -version

RAA container runs RAA on Java 11, and is supplied with the following of JDBC drivers:

  • MSSQL 9.2.1 JDBC Driver
  • Postgres 42.2.11 JDBC Driver
  • Oracle Database 21c (21.1) JDBC Driver

Genesys recommends that you verify whether the provided driver is compatible with your database, and if it is not, you can override the JDBC driver by copying an updated driver file to the folder lib\jdbc_driver_<RDBMS> within the mounted config volume, or by creating a co-named link within the folder lib\jdbc_driver_<RDBMS>, which points to a driver file stored on another volume (where <RDBMS> is the RDBMS used in your environment). This is possible because RAA is launched in a config folder, which is mounted in a container.

Download the Helm charts

To learn what Helm chart version you must download for your release, see Helm charts and containers for Genesys Customer Experience Insights.

You can download the gcxi helm charts from the following repository:

https://pureengage.jfrog.io/ui/packages/helm:%2F%2Fgcxi-raa

For more information about downloading containers, see: Downloading your Genesys Multicloud CX containers.

Third-party prerequisites

For information about setting up your Genesys Multicloud CX private edition platform, including Kubernetes, Helm, and other prerequisites, see Software requirements.

Storage requirements

This section describes the storage requirements for various volumes.

GIM secret volume

In scenarios where raa.env.GCXI_GIM_DB__JSON is not specified, RAA mounts this volume to provide GIM connections details.

  1. Declare GIM database connection details as a Kubernetes secret in gimsecret.yaml:
    apiVersion: v1
    kind: Secret
    metadata:
      namespace: gcxi
      name: gim-secret
    type: kubernetes.io/service-account-token
    data:
      json_credentials: eyJqZGJjX3VybCI6ImpkYmM6cG9zdGdyZXNxbDovLzxob3N0Pjo1NDMyLzxnaW1fZGF0YWJhc2U+IiwgImRiX3VzZXJuYW1lIjoiPHVzZXI+IiwgImRiX3Bhc3N3b3JkIjoiPHBhc3N3b3JkPiJ9Cg==
  2. Reference gimsecret.yaml in values.yaml:
    raa
      ...
      volumes:
        ...
        gimSecret:
          name: "gim-secret-volume"
          secretName: "gim-secret"
          jsonFile: "json_credentials"
       ...

Alternatively, you can mount the CSI secret using secretProviderClass, in values.yaml:

raa
  ...
  volumes:
    ...
    gimSecret:
      name: "gim-secret-volume"
      secretProviderClass: "gim-secret-class"
      jsonFile: "json_credentials"
   ...

Config volume

RAA mounts a config volume inside the container, as the folder /genesys/raa_config. The folder is treated as a work directory, RAA reads the following files from it during startup:

  • conf.xml, which contains application-level config settings.
  • custom *.ss files.
  • JDBC driver, from the folder lib/jdbc_driver_<RDBMS>.

RAA does not normally create any files in /genesys/raa_config at runtime, so the volume does not require a fast storage class. By default, the size limit is set to 50 MB. You can specify the storage class and size limit in values.yaml:

raa
  ...
  volumes:
    ...
    config:
      capacity: 50Mi
      storageClassName: "<vendor storage class>"
   ...

RAA helm chart creates a Persistent Volume Claim (PVC). You can define a Persistent Volume (PV) separately using the gcxi-raa chart, and bind such a volume to the PVC by specifying the volume name in the raa.volumes.config.pvc.volumeName value, in values.yaml:

raa
  ...
  volumes:
    ...
    config:
      pvc:
        volumeName: "my_raa_config_volume"
    ...

Health volume

RAA uses the Health volume to store:

  • Health files.
  • Prometheus file containing metrics for the most recent 2-3 scrape intervals.
  • Results of the most recent testRun init container execution.

By default, the volume is limited to 50MB. RAA periodically interacts with the volume at runtime, so Genesys does not recommend a slow storage class for this volume. You can specify the storage class and size limit in values.yaml:

raa
  ...
  volumes:
    ...
    health:
      capacity: 50Mi
      storageClassName: "<vendor storage class>"
   ...

RAA helm chart creates a PVC. You can define a PV separately using the gcxi-raa chart, and bind such a volume to the PVC by specifying the volume name in the raa.volumes.health.pvc.volumeName value, in values.yaml:

raa
  ...
  volumes:
    ...
    health:
      pvc:
        volumeName: "my_raa_helath_volume"
    ...


Network requirements

RAA interacts only with the Genesys Info Mart database.

RAA can expose Prometheus metrics by way of Netcat.

The aggregation pod has it's own IP address, and can run with one or two running containers. For Helm test, an additional IP address is required -- each test pod runs one container.

Genesys recommends that RAA be located in the same region as the Genesys Info Mart database.

Secrets

RAA secret information is defined in the values.yaml file (line 89).

For information about configuring arbitrary UID, see Configure security.

Genesys dependencies

RAA interacts with Genesys Info Mart database only.

GDPR support

Not applicable.

Comments or questions about this documentation? Contact us for support!