Search optimisations

.circleci/config.yml

@@ -33,7 +33,7 @@ jobs:
       - run:
           name: deploy
           command: |
-            export CUSTOM_COMMIT_MESSAGE="[ci skip] Deploy website - based on $(git rev-parse HEAD) "
+            export CUSTOM_COMMIT_MESSAGE="[ci skip] Deploy website - based on $(git rev-parse HEAD)"
             yarn deploy
           no_output_timeout: 2m
 

docs/main/03-reference/19-kratix-config/kratix-config.md

@@ -1,9 +1,13 @@
 ---
-description: Configuring Kratix via the Config
-title: Kratix Config
+description: Configuring Kratix
+title: Configuring Kratix
 id: config
 ---
 
+Kratix can be configured and customised via two ConfigMaps; Kratix Config and Kratix Pipeline Adapter Config.
+
+## Kratix Config
+
 When Kratix starts, it reads the `kratix` `ConfigMap` from the
 `kratix-platform-system` namespace. This `ConfigMap` allow you to configure
 various parts of Kratix and follows the format outlined below. It is loaded when
@@ -12,8 +16,6 @@ the `kratix-platform-controller-manager` pod starts within the same namespace.
 If any changes are made to the `ConfigMap`, you will need to restart the
 `kratix-platform-controller-manager` pod to apply the updated configuration.
 
-
-
 ```yaml
 apiVersion: v1
 kind: ConfigMap
@@ -22,50 +24,97 @@ metadata:
   namespace: kratix-platform-system
 data:
   config: |
-
-    # Number of old successful pipeline pods to keep. Default is 5
-    numberOfJobsToKeep: 1
-
-    # Selective cache for Secrets to limit memory usage. Please ensure Secrets used by Kratix are
-    # created with label: app.kubernetes.io/part-of=kratix. Default is false.
+    numberOfJobsToKeep: 5
     selectiveCache: false
-
-    # interval in which the Kratix runs the Promises/Resources workflows
     reconciliationInterval: "10h"
-    # Timeout configuration of controller's leader election.
-
     controllerLeaderElection:
       leaseDuration: 15s
       renewDeadline: 10s
       retryPeriod: 2s
-
     workflows:
       jobOptions:
-        # Number of times Kubernetes retries a failing workflow Job before marking it failed.
-        # Kratix does not set a default for this field, so Kubernetes uses its own
-        # Job default (6) if it is omitted.
-        defaultBackoffLimit: 4
-      defaultImagePullPolicy: # can be `IfNotPresent`, `Always`, or `Never`
+        defaultBackoffLimit: 6
+      defaultImagePullPolicy: IfNotPresent # can be `IfNotPresent`, `Always`, or `Never`
       defaultContainerSecurityContext:
-        # Security context fields, e.g.:
         runAsNonRoot: false
-
     logging:
       level: "info" # one of info, warning, debug, trace
       structured: false # if true, emit logs as json
-
     telemetry:
       enabled: false
       endpoint: grafana-k8s-monitoring-alloy-receiver.default.svc.cluster.local:4317 # exporter endpoint
       protocol: grpc # or http
       insecure: true
       headers: # additional headers if required
         authorization: "Bearer <grafana-api-token>"
-
     featureFlags:
       promiseUpgrade: false # enable/disable promise revisions
 ```
 
+### numberOfJobsToKeep (default: 5)
+
+The total number of completed Kratix workflow jobs to keep in the cluster. The oldest jobs will be deleted as new jobs are created.
+
+### selectiveCache (default: false)
+
+Enable label selector caching of Secrets on the cluster to optimise memory usage. Secrets used by Kratix must be labelled with app.`kubernetes.io/part-of=kratix`.
+
+### reconciliationInterval (default: 10h)
+
+The interval on which Kratix will re-run the Workflows for both Promises and Resources.
+
+### controllerLeaderElection
+
+Timeouts for the kratix controller's leader election. Defaults:
+
+- leaseDuration: 15s
+- renewDeadline: 10s
+- retryPeriod: 2s
+
+### Workflows
+
+Default configurations for Kratix Workflows. Any options configured within individual workflows will take precedence over those in the Kratix Config.
+
+#### jobOptions
+
+Options for the Jobs that are created by Kratix Workflows.
+
+##### defaultBackoffLimit
+
+The number of times to retry a failing workflow Job before marking it failed. This configures the [backoffLimit](https://kubernetes.io/docs/concepts/workloads/controllers/job/#pod-backoff-failure-policy) in Workflow Jobs. This will default to the Kubernetes Job default of 6.
+
+#### defaultImagePullPolicy
+
+When to pull the images specified in Workflows. This configures the [imagePullPolicy](https://kubernetes.io/docs/concepts/containers/images/#updating-images) in Workflow Jobs. Can be `IfNotPresent`, `Always`, or `Never`
+
+#### defaultContainerSecurityContext
+
+The [Security Context](/main/reference/workflows#security-context) to apply to all Workflow Pods.
+
+### logging
+
+Logging configuration for the Kratix Controller Manager pod logs.
+
+#### level (default: "info")
+
+The log level. Can be "info", "warning", "debug" or "trace"
+
+#### structured (default: false)
+
+Set to true to emit logs as json.
+
+### telemetry
+
+Telemetry configuration for Kratix.
+
+### featureFlags
+
+Enable Kratix features. These are disabled by default.
+
+#### promiseUpgrade (default: false)
+
+Enable the use of Promise Revision and Resource Bindings to manage Resource upgrades.
+
 ## Kratix Pipeline Adapter Config
 
 When Kratix schedules work as part of either Promise or Resource workflows,

docs/main/05-learn-more/02-kratix-resources.mdx

@@ -11,7 +11,7 @@ In this page, we explore what those objects are.
 There are two categories of Objects that Kratix creates:
 
 1. The Objects it needs to execute the Workflows.
-1. The Objects that represent the Workflows output.
+1. The Objects that represent the Workflows' output.
 
 The diagram below shows all of the Objects Kratix creates. We dive deeper into what they are used for later.
 
@@ -80,7 +80,7 @@ Apart from the `status-writer`, all containers are actually set as `initContaine
 
 :::
 
-Kratix creates a new Job every time a new workflow needs to be executed. You can control the number of Jobs that Kratix keeps by setting `numberOfJobsToKeep` in the [Kratix Config](/main/reference/kratix-config/config) document.
+Kratix creates a new Job every time a new workflow needs to be executed. You can control the number of Jobs that Kratix keeps by setting `numberOfJobsToKeep` in the [Kratix Config](/main/reference/kratix-config/config).
 You can also configure how many times a failing workflow Job is retried by setting `backoffLimit` in the same ConfigMap. Kratix does not provide a default value for this field.
 
 ## Output Objects