Skip to content

Helm Charts Runtime Configuration

Overview

Helm Charts Runtime Configuration allows you to control how Helm packages are deployed and managed within Omnistrate. These configuration options correspond to the runtime behavior of Helm operations, providing fine-grained control over deployment strategies, timeouts, hooks, and upgrade behaviors.

The runtime configuration is specified using the helmRuntimeConfiguration struct on a service specification and can be applied during service plan creation or updates to customize how your Helm charts are processed.

Info

Runtime configuration parameters are optional and have sensible defaults. Only specify parameters when you need to override the default behavior for your specific use case.

Configuration Parameters

DisableHooks

Type: bool
Default: false
Helm Flag Equivalent: --no-hooks

Controls whether Helm hooks are executed during deployment operations.

services:
  - name: ExampleServiceName
    helmChartConfiguration:
        runtimeConfiguration:
            disableHooks: true

When to use:

  • Skip pre/post-install, pre/post-upgrade, or pre/post-delete hooks
  • Faster deployments when hooks are not required
  • Troubleshooting deployment issues caused by failing hooks

Example use case: If your Helm chart includes database migration hooks that are causing deployment failures, you can disable hooks temporarily to deploy the main application first.

Wait

Type: bool
Default: false
Helm Flag Equivalent: --wait

Determines whether Helm waits for all resources to be in a ready state before marking the deployment as successful.

services:
  - name: ExampleServiceName
    helmChartConfiguration:
        runtimeConfiguration:
            wait: true

When to use:

  • Ensure all Pods, PVCs, Services, and minimum number of Pods of Deployments/StatefulSets/ReplicaSets are ready
  • Guarantee that your application is fully operational before proceeding
  • Critical for production deployments where readiness is essential

Behavior: When enabled, Helm will wait until all Kubernetes resources reach their ready state or until the timeout is reached.

WaitForJobs

Type: bool
Default: false
Helm Flag Equivalent: --wait-for-jobs

Controls whether Helm waits for all Jobs to complete before marking the release as successful. This parameter only takes effect when Wait is also enabled.

services:
  - name: ExampleServiceName
    helmChartConfiguration:
        runtimeConfiguration:
            wait: true
            waitForJobs: true

When to use:

  • Applications that include initialization Jobs or batch processing
  • Database migrations or data seeding operations
  • Any scenario where Job completion is critical for application functionality

Note: This parameter requires Wait to be set to true to function properly.

TimeoutNanos

Type: uint64
Default: 300000000000 (5 minutes)
Helm Flag Equivalent: --timeout

Specifies the maximum time (in nanoseconds) to wait for any individual Kubernetes operation.

services:
  - name: ExampleServiceName
    helmChartConfiguration:
        runtimeConfiguration:
            timeoutNanos: 600000000000  # 10 minutes

Common timeout values:

  • 1 minute: 60000000000
  • 5 minutes: 300000000000 (default)
  • 10 minutes: 600000000000
  • 30 minutes: 1800000000000

When to adjust:

  • Large applications that take longer to start
  • Complex deployments with many dependencies
  • Environments with slower resource provisioning

SkipCRDs

Type: bool
Default: false
Helm Flag Equivalent: --skip-crds

Controls whether Custom Resource Definitions (CRDs) are installed during the deployment.

services:
  - name: ExampleServiceName
    helmChartConfiguration:
        runtimeConfiguration:
            skipCRDs: true

When to use:

  • CRDs are already installed in the cluster
  • Managing CRDs separately from application deployments
  • Avoiding conflicts with existing CRD versions

Important: Skipping CRDs when they're required by your application will cause deployment failures.

UpgradeCRDs

Type: bool
Default: false
Helm Flag Equivalent: Related to CRD upgrade behavior

Determines whether CRDs should be upgraded during Helm operations.

services:
  - name: ExampleServiceName
    helmChartConfiguration:
        runtimeConfiguration:
            upgradeCRDs: true

When to use:

  • Ensuring CRDs are kept up-to-date with chart versions
  • Automated CRD lifecycle management
  • Charts that include CRD updates

Caution: CRD upgrades can be disruptive and should be tested thoroughly in non-production environments.

ResetValues

Type: bool
Default: false
Helm Flag Equivalent: --reset-values

When upgrading, resets the values to the ones built into the chart, ignoring any previously set values.

services:
  - name: ExampleServiceName
    helmChartConfiguration:
        runtimeConfiguration:
            resetValues: true

When to use:

  • Starting fresh with default chart values
  • Removing all custom configurations from previous deployments
  • Troubleshooting configuration-related issues

Warning: This will remove all custom values from previous deployments.

ReuseValues

Type: bool
Default: false
Helm Flag Equivalent: --reuse-values

When upgrading, reuses the last release's values and merges in any new overrides.

services:
  - name: ExampleServiceName
    helmChartConfiguration:
        runtimeConfiguration:
            reuseValues: true

When to use:

  • Preserving existing configuration during upgrades
  • Incremental configuration changes
  • Maintaining consistency across deployments

Note: This is mutually exclusive with ResetValues and ResetThenReuseValues.

ResetThenReuseValues

Type: bool
Default: false
Helm Flag Equivalent: --reset-then-reuse-values

When upgrading, first resets values to chart defaults, then applies the last release's values, and finally merges in any new overrides.

services:
  - name: ExampleServiceName
    helmChartConfiguration:
        runtimeConfiguration:
          resetThenReuseValues: true

When to use:

  • Ensuring clean configuration state while preserving custom values
  • Complex upgrade scenarios where value precedence matters
  • Resolving configuration conflicts

Behavior: This provides a three-step process: reset → reuse → merge new values.

Recreate

Type: bool
Default: false
Helm Flag Equivalent: --force (similar behavior)

Forces resource updates through a replacement strategy, recreating resources if they already exist.

services:
  - name: ExampleServiceName
    helmChartConfiguration:
        runtimeConfiguration:
            recreate: true

When to use:

  • Resolving resource conflicts or corruption
  • Forcing updates to immutable fields
  • Recovery from failed deployments

Caution: This can cause service interruption as resources are deleted and recreated.

Complete Configuration Example

services:
  - name: My Application
    helmChartConfiguration:
      chartName: my-app
      chartVersion: 1.0.0
      chartRepoName: my-repo
      chartRepoURL: https://charts.example.com
      helmRuntimeConfiguration:
        disableHooks: false
        wait: true
        waitForJobs: true
        timeoutNanos: 600000000000  # 10 minutes
        skipCRDs: false
        upgradeCRDs: true
        resetValues: false
        reuseValues: true
        resetThenReuseValues: false
        recreate: false
      chartValues:
        app:
          name: "my-application"
          replicas: 3

Troubleshooting

Common Issues and Solutions

Deployment Timeouts:

  • Increase timeoutNanos value
  • Check if wait and waitForJobs are necessary
  • Verify resource requests and limits

Hook Failures:

  • Set disableHooks: true to bypass problematic hooks
  • Review hook configurations in your Helm chart

CRD Conflicts:

  • Use skipCRDs: true if CRDs are managed separately
  • Enable upgradeCRDs: true for automatic CRD updates

Configuration Issues:

  • Use resetValues: true to start with clean configuration
  • Enable reuseValues: true to preserve existing settings