HELM Configuration

The following Pyramid services configuration should be added to values.yaml to enable a HELM install.

Note: These fields are used in the values.yaml created when performing a deployment of Pyramid using HELM charts. For more information about the overall process, see Install Pyramid using HELM.

Fields and values

Docker Settings:

• repo* : The Docker registry to pull the images from.
• imagePullPolicy* : The policy to use when pulling images from the Docker registry. By default, this is "ifNotPresent", indicating that images should only be pulled if they are not already present locally.

Attendance:

• unattended* : Where applicable, the details for the unattended install.
  • enabled* : Indicates whether the installation should run in the unattended mode or not:
    • If "false", the installation will be "attended". In this case, there is no "installationData" block. Instead, the Installation UI opens for you to enter your installation settings.
    • If "true", the installation will be "unattended". In this case, you also need to add the sibling "installationData" block for your installation settings (the database and storage settings that enable the unattended installation).
  • installationData: The installationData block contains the database and storage fields required to perform an unattended installation. As shown in the following example, the installationData block is contained by the unattended block and is only used where the unattended installation is enabled.

Local storage

• storage: Root for local storage details. These details are used when you create the mount using HELM.
  • type: Type of local storage. Can be one of "GoogleStore", "NFS", or "other".
    • Where type is "other", local storage is not used, and FTP, S3, or Azure Blob is used instead. In this case, the storage should be configured in the web UI or in the unattended installation configuration.
    • Where type is "NFS", HELM templates are used to create local storage. You need to specify size and nfs attributes as described below.
    • Where type is "GoogleStore", HELM templates are used to create local storage. You need to specify size and GoogleStore attributes as described below.
  • size: Minimum size of local storage. Not required for type "other".
  • nfs: NFS server settings, only required if the type is NFS. The path and ip attributes describe where the storage is available.
  • GoogleStore: The file store on GCP, only required if the type is GoogleStore. The child network attribute specifies the VPC network that the file store instance will be created on.

Service settings

In addition to the preceding details, it is also necessary to provision initialization settings for each of the services. Each block of settings sits at the root of the yaml file and contains the following settings:

Web server

The Web server handles HTTP networking and authentication.

• ws:
  • port: The default port for your web server. Match this with your ingress.
  • replicas: The number of replicas (pods) required for this service
  • requests: The minimum memory, CPU, and ephemeral_storage guaranteed for the service. Tip: We recommend that you only increase and do not reduce the default values.
  • limits: The memory limits for the service (memory, cpu, and ephemeral_storage). You can increase these values to better match your nodes, but do not typically need to do so. Note: The main limitation for web servers specifically is IO.
  • kedaAutoscaling: The "auto-scale" settings where Keda is enabled.
    • enabled: Whether auto-scaling is enabled for this service.
    • minReplicas: The minimum number of replicas for this service. Note: Auto-scaling will never reduce the number of pods below this number.
    • maxReplicas: The maximum number of replicas for this service. Note: Auto-scaling will never increase the number of pods above this number.
    • threshold: The number of active requests that the server can handle before the auto-scaling threshold is met. If maxReplicas has not been met, meeting this threshold causes a new replica to be added.

Routing service

The Router Server is used to route all internal requests between the different nodes in the Pyramid cluster.

• rtr:
  • replicas: As above.
  • requests: As above.
  • limits: As above.

Runtime engine

The Runtime engine handles all active requests, queries, and the CMS.

• rte:
  • replicas: As above.
  • requests: As above.
  • limits: As above.
  • satellites: The number of satellites used to preview Data Flow results.
  • autoscaling: The standard "auto scale" settings. The settings indicate the min and max number of replicas, the target CPU utilization, and the scale down duration when auto scaling.
    • enabled: Whether auto-scaling is enabled for this service.
    • minReplicas: The minimum number of replicas for this service. Note: Auto-scaling will never reduce the number of pods below this number.
    • maxReplicas: The maximum number of replicas for this service. Note: Auto-scaling will never increase the number of pods above this number.
    • targetCpuUtilization: The percentage of CPU usage across all pods associated with this service before the auto-scaling threshold is met. If maxReplicas has not been met, meeting this threshold causes a new replica to be added.

Natural language (NLP)

The Natural language processing engine is responsible for the chat bot function in Discover.

• nlp:
  • replicas: As above.
  • requests: As above.
  • limits: As above. Note: Based on system usage, NLP can be CPU heavy.
  • autoscaling: As above.

Task engine

The Task engine handles Data Flow (ETL) and prints.

• te:
  • replicas: As above.
  • requests: As above.
  • limits: As above. Note: Task Engine can be CPU and memory heavy.
  • satellites: As above.
  • kedaAutoscaling:
    • enabled: As above.
    • minReplicas: As above.
    • maxReplicas: As above.
  • terminationGracePeriodSeconds: A grace period for a termination to complete after a termination signal is sent to the pod. If the termination is not completed by the end of the grace period, it is forced. If you do not supply a grace period, the default is 30 seconds.
  • printers : The actual number of print "engines" available at all times, per task engine service.

DS/ML

The DS/ML server hosts all Python and R script handling.

• ai:
  • replicas: As above.
  • requests: As above.
  • limits: As above. Note: Based on system usage, AI can be CPU heavy.
  • satellites: As above.
  • autoscaling: As above.
  • full: Boolean. Select either the full DS/ML server or the standard version by specifying true or false, respectively; the main difference being the incorporated Python Package (Anaconda in the full version and Miniconda in the standard version). The key advantages of installing the full version are offline installation and faster environment installation, although it is heavier.

GeoSpatial server

The GeoSpatial server handles mapping data for queries. Can be disabled if not in use.

• gis:
  • enabled: Set to "true" if the GeoSpatial server is in use. Otherwise, set to "false".
  • requests: As above.
  • limits: As above.

Solve server

The optional Solve service enables Optimizations in Tabulate.

• solve:
  • requests: As above.
  • limits: As above.
  • replicas: As above. Note: Set replicas to 0 if you do not use Solve.
  • autoscaling: As above.

Examples