Helm chart

This is a summary of the Helm chart parameters that can be used to customise the SDP deployment. The current default values can be found in the chart’s values file.

Configuration database

The configuration database is implemented on top of etcd.

Parameter	Description	Default
`etcd.image`	etcd container image	`quay.io/coreos/etcd`
`etcd.version`	etcd container version	`3.3.27`
`etcd.imagePullPolicy`	etcd container image pull policy	`IfNotPresent`
`etcd.replicas`	Number of etcd server replicas	`1`
`etcd.persistence.enabled`	Enable persistence of etcd database in persistent volume claim	`false`
`etcd.persistence.size`	Size of persistent volume claim	`1Gi`
`etcd.persistence.storageClassName`	Storage class name for persistent volume claim	`standard`
`etcd.persistence.autoCompaction.retention`	Auto compaction retention for key-value store in hours	`0`
`etcd.persistence.autoCompaction.mode`	Auto compaction mode	`periodic`
`etcd.persistence.defrag.enabled`	Enable periodic etcd defragmentation	`false`
`etcd.persistence.defrag.cronjob.schedule`	Schedule in Cron format for etcd defragmentation	`30 23 * * 3,7`
`etcd.persistence.defrag.cronjob.historyLimit`	Number of successful finished jobs to retain	`1`
`etcd.maxTxnOps`	Maximum number of operations per transaction	`1024`

Console

The console provides a command-line interface to monitor and control the SDP by interacting with the configuration database.

Parameter	Description	Default
`console.enabled`	Enable the console	`true`
`console.image`	Console container image	`artefact.skao.int/ska-sdp-console`
`console.version`	Console container version	See values file
`console.imagePullPolicy`	Console container image pull policy	`IfNotPresent`

Processing controller

Parameter	Description	Default
`proccontrol.image`	Processing controller container image	`artefact.skao.int/ska-sdp-proccontrol`
`proccontrol.version`	Processing controller container version	See values file
`proccontrol.imagePullPolicy`	Processing controller container image pull policy	`IfNotPresent`
`proccontrol.loopInterval`	Processing controller idle loop time (seconds)	See values file
`proccontrol.livenessProbe`	Processing controller Kubernetes liveness probe configuration	See values file

Data Persistent Volume Claim (PVC)

Configure the SDP to use an existing volume or create a new one, and then configure the processing scripts to write the data to that volume. When creating new PVCs, one will be created in the control system namespace and the other in the processing namespace.

Parameter	Description	Default
`global.data-product-pvc-name`	Name of data product PVC that is set as a global value to allow subcharts to access the same PVC	`test-pvc`
`data-pvc.create.enabled`	Enable creation of PVCs	`false`
`data-pvc.create.size`	Size of PVC	`5Gi`
`data-pvc.create.storageClassName`	Storage class name for PVC	`standard`

Processing scripts

Processing script definitions to be used by SDP. These map the script kind, name and version to a container image. By default the definitions are read from the scripts repository in GitLab. A different URL may be specified. Alternatively a list of script definitions can be passed to the chart.

Parameter	Description	Default
`scripts.url`	URL from which to read the script definitions	`https://gitlab.com/ska-telescope/sdp/ska-sdp-script/-/raw/master/scripts.json`
`scripts.definitions`	List of script definitions. If present, used instead of the URL. See the example below	Not set

Example of script definitions in a values file:

scripts:
  definitions:
  - type: realtime
    id: test-realtime
    version: 0.3.0
    image: artefact.skao.int/ska-sdp-script-test-batch:0.3.0
  - type: batch
    id: test-batch
    version: 0.3.0
    image: artefact.skao.int/ska-sdp-script-test-realtime:0.3.0

Helm deployer

Parameter	Description	Default
`helmdeploy.image`	Helm deployer container image	`artefact.skao.int/ska-sdp-helmdeploy`
`helmdeploy.version`	Helm deployer container version	See values file
`helmdeploy.imagePullPolicy`	Helm deployer container image pull policy	`IfNotPresent`
`helmdeploy.namespace`	Namespace for SDP dynamic deployments	`sdp`
`helmdeploy.releasePrefix`	Prefix for Helm release names	`""`
`helmdeploy.chartPrefix`	Prefix for Helm chart names	`""`
`helmdeploy.chartRepo.url`	Chart repository URL	`https://gitlab.com/ska-telescope/sdp/ska-sdp-helmdeploy-charts/-/raw/master/chart-repo/`
`helmdeploy.chartRepo.refresh`	Chart repository refresh interval (in seconds)	`0`
`helmdeploy.loopInterval`	Helm deployer idle loop time (seconds)	See values file
`helmdeploy.livenessProbe`	Helm deployer Kubernetes liveness probe configuration	See values file

LMC (Tango devices)

Parameter	Description	Default
`lmc.enabled`	Enable the LMC. If set to `false`, the SDP will run in headless mode	`true`
`lmc.image`	LMC container image	`artefact.skao.int/ska-sdp-lmc`
`lmc.version`	LMC container version	See values file
`lmc.imagePullPolicy`	LMC container image pull policy	`IfNotPresent`
`lmc.nsubarray`	Number of subarrays to deploy	`1`
`lmc.prefix`	Telescope prefix for Tango device names (e.g. `low` or `mid`)	`test`
`lmc.newDeviceNames`	Use new-style Tango device names defined in ADR-9	`true`
`lmc.allCommandsHaveArgument`	Enable all Tango device commands to receive a transaction ID	`false`
`lmc.strictValidation`	Enable strict validation of subarray command schemas	`false`
`lmc.loopInterval`	LMC devices idle loop time (seconds)	See values file
`lmc.livenessProbe`	LMC devices Kubernetes liveness probe configuration	See values file

Tango infrastructure

Parameters for the ska-tango-base subchart and Tango dsconfig. The ska-tango-base subchart must be enabled to support the Tango devices when running the SDP stand-alone.

Parameter	Description	Default
`ska-tango-base.enabled`	Enable the ska-tango-base subchart	`true`
`ska-tango-base.itango.enabled`	Enable the itango console in the ska-tango-base subchart	`false`
`dsconfig.image.*`	Tango dsconfig container image settings	See values file

Proxy settings

Proxy settings are applied to the components that retrieve configuration data via HTTPS: the script definitions and the Helm charts.

Parameter	Description	Default
`proxy.server`	Address of proxy server	Not set
`proxy.noproxy`	List of addresses or subnets for which the proxy should not be used	Not set

Example of proxy settings in a values file:

proxy:
  server: http://proxy.mydomain
  noproxy:
  - 192.168.0.1
  - 192.168.0.2

Networking Setup (Network Attachment Definition)

A Processing Block using the vis-receive script that needs to use a Kubernetes Network Attachment Definition a networking.setup must be defined here and the following option specified in the processing block configuration parameters.

"use_network_definition": True

The networking.setup is only added to SDP etcd when networking.setup.network-attachment-definition is not empty.

Parameter	Description	Default
`networking.setup`	Networking setup
`networking.setup.network-attachment-definition`	As required by Kubernetes to access device	`{}`
`networking.setup.network-attachment-definition.name`	The name for the Kubernetes network attachment definition	None set
`networking.setup.network-attachment-definition.namespace`	The namespace containing the Kubernetes network attachment definition	None set
`networking.setup.available-ipv4-network`	IP network in CIDR form used to allocate one or more IP network(s) for externally facing services that directly use host network devices, like `vis-receive`.	None set
`networking.setup.allocate-subnets-cidr-bits`	Number of network bits to use in IP range allocation	None set

Example of network setup that will NOT not be used due to empty dict in a values file.

Note

If the available-ipv4-network and allocate-subnets-cidr-bits are specified then they will be ignored.

networking:
  setup:
    network-attachment-definition: {}

Example of networking setup defining a network attachment definition in a values file:

networking:
  setup:
    network-attachment-definition:
      name: ska-low-sdn-static
      namespace: kube-system
    available-ipv4-network: 192.168.21.0/23
    allocate-subnets-cidr-bits: 24