Hydrolix Tunables

Tunables overview

Hydrolix uses tunables, a set of YAML key-value pairs, to configure Hydrolix cluster and secrets behavior, referred to as Hydrolix tunables.

In version 5.0, Hydrolix added the Hydrolix Tunable Names (HTN) naming convention to give a more granular level of control over cluster behavior. These HTN tunables work in conjunction with the existing Hydrolix tunables.

Hydrolix defines all tunables in the hydrolixcluster.yaml file, under spec:.

Hydrolix tunables

Hydrolix tunables are used to provide global Hydrolix cluster control, and affect all levels of the cluster. See the Hydrolix Tunables List for more information.

Examples of Hydrolix tunables

decay_reap_batch_size
http_response_timeout_ms
prometheus_scrape_interval

HTN tunables

HTN tunables can be set at different levels: service, pool, and container. The HTN convention provides a clear naming structure and fine control over cluster behavior.

Format structure for HTN tunables

HTN tunables follow a specific naming convention:

htn:tunable_name:service_name:pool_name:container_name: value

The key components for each HTN tunable are:

htn: Prefix indicates the tunable uses the HTN naming structure
tunable_name: The tunable parameter name
value: The tunable value
service_name: (Optional) The service where the tunable is applied, can be omitted by using an empty string
pool_name: (Optional) The pool in the service, can be left empty
container_name: (Optional) The specific container in the pool and service, can be left empty

Tunable precedence order

HTN tunables take precedence over Hydrolix tunables. If no HTN tunable exists in the hydrolixcluster.yaml file, Hydrolix uses the non-HTN tunable. If neither an HTN or Hydrolix tunable exists, Hydrolix uses the system default.

Scheduled overrides

You can automate temporary overrides for any tunable using scheduled overrides.

Overrides are specified within the Hydrolix spec configuration and take effect when the container's current time falls within the schedule block specified for an override. The HDX custom resource definition itself is never mutated by the contents of the overrides block. Instead, overrides live only in the operator memory.

Example scheduled overrides

The following are example configuration blocks to create schedule overrides. For configuration information, scale-related examples, limitations, and verification steps, see the scheduled overrides page.

spec:
  overrides:
    linode-quiet-weekends:
      timezone: America/Los_Angeles
      weekly:
        days: ["Fri..Mon"]
        start: "17:00"
        end: "08:00"
      patch:
        silence_linode_alerts: true # turn off Linode alerts for LKE nodes

# reduce ingest (intake-head) to 1 replica with minimal CPU and memory allocation and disable intake spill functionality
# gameday an overwhelmed intake-head replica 
spec:
  overrides:
    gameday-reduce-ingest-disable-spill:
      timezone: Europe/Vatican
      window:
        start: "2025-07-30T10:00:00Z"
        end: "2025-07-30T10:30:00Z"
      patch:
        pools:
          intake-head:
            replicas: 1
            cpu: 1
            memory: 2Gi
        intake_head_catalog_spill_config:
          enabled: false
        intake_head_raw_data_spill_config:
          enabled: false

spec:
  overrides:
    november-no-prometheus:
      timezone: Brazil/East
      cron:
        expression: "0 11 11 11 11 ?" # Fire every November 11 at 11:11 AM
        duration: "11h"
      patch:
        prometheus_enabled: false # disable prometheus