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.
| Setting | Required | Default | Description |
|---|---|---|---|
settings.companyName | Yes | Your company's name as Chronolog shows it in its header, for example Example Co |
Secret settings
Passwords, keys and other values to keep private.
| Name | Required | Description |
|---|---|---|
ENTRA_TENANT_ID | Yes | Your Microsoft Entra tenant's ID |
ENTRA_CLIENT_ID | Yes | The application (client) ID of the app registration admins sign in to Chronolog with at Microsoft Entra ID |
ENTRA_CLIENT_SECRET | Yes | The client secret of the app registration admins sign in to Chronolog with at Microsoft Entra ID |
NOTIFICATION_SERVICE_CLIENT_ID | Yes | The 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.envIn chronolog.yaml, give only the Secret's name:
secrets:
existingSecret: chronolog-settingsTo 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.yamlIt 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.