Skip to Content
RigFabTech docs
Products

chronolog settings

What chronolog needs from you before it installs. It goes in one small file, chronolog.yaml, which you pass to helm install and helm upgrade after site.yaml, as Install shows.

Starter file

chronolog.yaml holds every setting on this page with its description. Save it, replace each <PLACEHOLDER> and remove the optional lines you don't need. chronolog.schema.json describes the file to editors that check YAML against a JSON schema.

Settings

Plain values, under settings in chronolog.yaml.

SettingRequiredDefaultDescription
settings.companyNameYesYour company's name as Chronolog shows it in its header, for example Example Co

Secret settings

Passwords, keys and other values to keep private.

NameRequiredDescription
ENTRA_TENANT_IDYesYour Microsoft Entra tenant's ID
ENTRA_CLIENT_IDYesThe application (client) ID of the app registration admins sign in to Chronolog with at Microsoft Entra ID
ENTRA_CLIENT_SECRETYesThe client secret of the app registration admins sign in to Chronolog with at Microsoft Entra ID
NOTIFICATION_SERVICE_CLIENT_IDYesThe application (client) ID of notification-service's app registration at Microsoft Entra ID; Chronolog needs it to call notification-service

Give them in one of two ways, never both.

In production, in a Secret of your own. A values file with passwords in it tends to end up in git, and Helm keeps a copy of the values you pass in its release record in the cluster. Write the values to a file, chronolog.env, one NAME=value per line with each value as it is, without quotes, then create the Secret and delete the file:

kubectl create secret generic chronolog-settings --namespace rft-app-chronolog --from-env-file=chronolog.env
rm chronolog.env

In chronolog.yaml, give only the Secret's name:

secrets:
  existingSecret: chronolog-settings

To keep the Secret in git or a secret store instead, create it with External Secrets Operator, SOPS or Sealed Secrets, with the same keys.

The Secret needs a key for every required name above. When one is missing, the product's pods don't start: kubectl --namespace rft-app-chronolog get pods shows CreateContainerConfigError or Init:CreateContainerConfigError, and kubectl --namespace rft-app-chronolog describe pods names the missing key. Add it and the pods start by themselves. After you change a value in the Secret, restart the product with kubectl --namespace rft-app-chronolog rollout restart deployment.

To get started, in the values file. Under secrets in chronolog.yaml, as the starter file has them. The chart keeps them in the Secret chronolog-env.

Made for you

The platform makes these once and keeps them in the Secret chronolog-generated. There is nothing to set.

  • ADMIN_SESSION_KEY

In site.yaml

chronolog answers on chronolog.<domain>, under your global.rigfab.domain. To give it another name, set global.rigfab.hosts.chronolog to the full host name.

Check before you install

Once the base chart is installed, and before you install or upgrade this product:

rft check --chart oci://registry.rigfab.com/rft/apps/chronolog/charts/chronolog --version <VERSION> --release chronolog --namespace rft-app-chronolog --values site.yaml --values chronolog.yaml

It renders the chart with your files and asks the cluster whether it would accept the result, and changes nothing. A setting that is missing or misspelt in your files stops it with a message that names the setting. It doesn't look inside a Secret of your own. A misspelt name under global.rigfab is the base chart's to refuse, so check site.yaml with the base chart after every change to it, as Install shows.