Thoras Documentation

Using ArgoCD to deploy Thoras

The Thoras Helm chart is designed to render deterministically for GitOps tools. Credentials are never generated at template time: anything you don’t supply is seeded in-cluster by the Thoras config-controller, and anything you pin in values.yaml is rendered verbatim. Two things still need attention:

Disable legacy secret seeding. Set featureFlags.enableLegacySecretSeeding: false. The flag defaults to true only so clusters upgrading from chart 4.x can migrate their pre-existing credentials. The legacy Secrets it renders use Helm lookup, which Argo CD cannot evaluate. If you are upgrading from 4.x, complete the upgrade with the flag on, then set it to false once the pods are healthy. During that upgrade window, keep jsonPointers: [/data] ignoreDifferences entries for the api-client-secret and thoras-timescale-password Secrets so Argo CD does not overwrite them with freshly-rendered random values before the config-controller has migrated them. Remove those entries once the flag is false. See Upgrading.
Ignore fields that are managed in-cluster. The webhook caBundle is injected after apply (by the chart’s cert-generator or by cert-manager), and the thoras-forecast-worker replica count is managed by Thoras’s built-in scaler. Add both to spec.ignoreDifferences.

Example Application config

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: thoras
  namespace: argocd
spec:
  project: default
  source:
    chart: thoras
    helm:
      parameters:
        - name: imageCredentials.password
          value: <Thoras License Key>
        - name: featureFlags.enableLegacySecretSeeding
          value: "false"
    repoURL: https://thoras-ai.github.io/helm-charts
    targetRevision: <Thoras Chart Version>
  destination:
    namespace: thoras
    server: https://kubernetes.default.svc
  syncPolicy:
    automated: {}
  ignoreDifferences:
    # The webhook caBundle is injected in-cluster after apply.
    - group: admissionregistration.k8s.io
      kind: MutatingWebhookConfiguration
      jqPathExpressions:
        - ".webhooks[]?.clientConfig.caBundle"
    - group: admissionregistration.k8s.io
      kind: ValidatingWebhookConfiguration
      jqPathExpressions:
        - ".webhooks[]?.clientConfig.caBundle"
    # Forecast worker replicas are managed by Thoras at runtime.
    - jsonPointers:
        - /spec/replicas
      kind: Deployment
      name: thoras-forecast-worker

The chart’s default webhook certificate flow uses Helm hook Jobs (pre-install, pre-upgrade), which GitOps tools do not handle well. If you run cert-manager, set thorasOperator.webhookCertGen.certManager.enabled: true to replace those Jobs with declarative Issuer and Certificate resources. See Webhook TLS with cert-manager.

Credential rotation under GitOps

When a credential changes (you rotate a pinned value in values.yaml, update a Secret you manage, or delete a generated key so it is re-seeded), the config-controller restarts the affected Thoras workloads for you. It does this by evicting pods rather than patching the Deployment’s pod template, so the restart never shows up as drift in Argo CD. No kubectl rollout restart is needed. See Credentials.

Flux

The same guidance applies to Flux: set featureFlags.enableLegacySecretSeeding: false and prefer cert-manager for webhook TLS. Additionally set flux.enabled: true so Flux’s drift detection does not revert the operator’s own rollout restarts:

flux:
  enabled: true

Using ArgoCD to manage a Thoras horizontally controlled workload

When Thoras manages horizontal scaling for a workload, it uses a validation webhook to prevent the default Kubernetes Horizontal Pod Autoscaler (HPA) from reducing replicas during anticipated usage spikes. By design, this ensures workloads remain scaled up until Thoras determines it’s safe to scale down. However, ArgoCD interprets these blocked scale-down attempts as HPA errors. This can cause the Application to appear in a degraded state even though the workload is healthy. To prevent this, you can customize ArgoCD’s health assessment logic for HPAs so that these Thoras-specific conditions are handled correctly.

When Do I Need This?

You only need this customization if all of the following are true:

The workload is horizontally controlled by Thoras.
You are using ArgoCD to monitor the workload state.
You notice ArgoCD incorrectly marking the HPA as Degraded when Thoras blocks a scale-down.

If your workloads are not using Thoras for horizontal scaling, this customization is unnecessary. 1. Edit the ArgoCD ConfigMap: Open the argocd-cm ConfigMap in the argocd namespace:

kubectl edit configmap argocd-cm -n argocd

2. Add the following customizations under data:

resource.customizations.useOpenLibs.autoscaling_HorizontalPodAutoscaler: "true"
resource.customizations.health.autoscaling_HorizontalPodAutoscaler: |
  hs = {}
  if obj.status ~= nil then
    if obj.status.conditions ~= nil then
      for i, condition in ipairs(obj.status.conditions) do
        -- Mark Degraded only for certain conditions
        if condition.type == "Ready" and condition.status == "False" then
          hs.status = "Degraded"
          hs.message = condition.message
          return hs
        end
        -- Ignore AbleToScale=False with FailedUpdateScale reason caused by Thoras
        if condition.type == "AbleToScale" and condition.status == "False" and condition.reason == "FailedUpdateScale" and string.find(condition.message or "", "target is already at Thoras desired replicas") ~= nil then
          hs.status = "Healthy"
          hs.message = "Target is at Thoras desired replicas"
          return hs
        end
        -- Mark Healthy for Ready=True or ScalingActive=True
        if (condition.type == "Ready" or condition.type == "ScalingActive") and condition.status == "True" then
          hs.status = "Healthy"
          hs.message = condition.message
          return hs
        end
      end
    end
  end

  hs.status = "Progressing"
  hs.message = "Waiting for HPA to become healthy"
  return hs

3. Restart ArgoCD components (to apply changes):

kubectl rollout restart deployment argocd-repo-server -n argocd
kubectl rollout restart deployment argocd-applicationset-controller -n argocd

Getting Started

Installation

Guides

ArgoCD

Using ArgoCD to deploy Thoras

Example Application config

Credential rotation under GitOps

Flux

Using ArgoCD to manage a Thoras horizontally controlled workload

When Do I Need This?

​Using ArgoCD to deploy Thoras

​Example Application config

​Credential rotation under GitOps

​Flux

​Using ArgoCD to manage a Thoras horizontally controlled workload

​When Do I Need This?

Using ArgoCD to deploy Thoras

Example Application config

Credential rotation under GitOps

Flux

Using ArgoCD to manage a Thoras horizontally controlled workload

When Do I Need This?