Function

In ConfigHub, configuration data is separate from the code that operates on it.

A Function is a executable piece of code that operates on configuration data in Config Units that ConfigHub can invoke.

Functions operate on configuration elements that are (mostly) standard APIs with defined schemas and backward compatibility guarantees in well known stable formats, such as Kubernetes resources represented in YAML.

There are multiple ways one can think about functions:

  • Each function is kind of a mini tool or command that performs a specific operation on specific kinds of configuration data. These mini tools should be reusable across all configuration Units containing the configuration elements of the same types. An example is the set-image-reference function, which can update image references according to the OCI standard in all Kubernetes workload types.
  • Function invocation is a kind of an API extension mechanism. It enables the same functionality to be accessible via CLI, UI, and automation systems that call the ConfigHub API.
  • When configured as a Trigger, a function acts similarly to a dynamic admission controller in Kubernetes.
  • Functions are an extension point that enables ConfigHub to support additional ToolchainTypes for other configuration formats, by implementing them in workers.
  • Functions provide a means of making operations, such as validation and policy checks, with consistent behavior available to your organization.

Your preferred AI tools can be used to make ad hoc configuration changes directly that can be explained concisely and simply and are easy to validate, and those changes can be patched to similar units by using the original unit as a merge source for updates. We recommend using AI to help you create and test functions for operations on configurations that need to be performed repeatedly reliably and predictably, such as when making changes to many units, or automating changes in CI or in systems using ConfigHub's API as a control/management plane. Functions can also more easily encode conditional logic based on configuration data values.

There are 3 types of Functions:

  1. Readonly
  2. Mutating
  3. Validating

A Readonly Function extracts or analyzes specific pieces of data from a Config Unit and returns the results. For example it may extract the container image URI from a Unit containing a Kubernetes Deployment. A Mutating function takes a Config Unit as input, makes changes to it and writes and returns the mutated Unit. For example, a Mutating function may update the Postgres version in a set of OpenTofu config Units. A Validating function takes Config Units as input and returns simple pass/fail for each Unit.

Functions most commonly run synchronously, hermetically, and idempotently, with no side effects. But it is possible for functions to interact with external systems. The main constraint is that functions are expected to return synchronously and therefore must complete without long delays.

Similar to Bridge Workers, ConfigHub supplies a prebuilt Worker with a range of Functions. Developers can custom build their own Workers with their own set of Functions in addition to the prebuilt ones. You can start from the code in the [https://github.com/confighub/sdk] repo.

In addition to imperative Function invocation, ConfigHub supports automatic function Triggers, which is a major reason functions aren't entirely external to ConfigHub.

(ConfigHub functions were inspired by KRM functions and Kustomize transformations, but support more than just KRM YAML, transform configuration data in place rather than out of place, support more use cases than just transformation and validation, are API-driven rather than file- and CLI-driven, are not attached to individual configuration Units, have a model for passing data across configuration Units, and are executed by workers rather than in containers, among other differences.)