Skip to content

Needs/Provides

Infrastructure and Kubernetes resources often need information about other resources in order to be fully configured. The simplest example is references to identifiers of other resources. Network addresses are a common example in infrastructure resources. Needs/Provides is a way to formally express what values a resource needs and what values a resource provides. For example, a Kubernetes Namespace provides a namespace name. Most Kubernetes resources, such as Deployment and Service, need a namespace.

By capturing complete Needed and Provided information from all resources, it is possible to mostly automate the "wiring" of Config Units to each other.

Needed and Provided values differ from Infrastructure as Code module/template input and output variables in that they are not specific to a particular Config Unit, but are intrinsic to the resource types contained within the configuration data, and are applicable to all Config Units containing those resources types. It's extended schema information.

Provided values can fulfill Needed values within the same Unit and in Units linked to the providing Unit.

Seeing what was identified

Needed and Provided values are identified automatically, and what was identified is recorded on the Unit itself, in two read-only fields:

  • NeededPaths — the paths this Unit needs a value for, computed by the get-needed function.
  • ProvidedPaths — the paths this Unit offers to others, computed by get-provided.

Both are recomputed when the Unit's configuration data changes, so they follow the data rather than having to be declared. cub unit get reports how many of each a Unit has, and --verbose prints them:

cub unit get --space my-space my-unit --verbose
cub unit get --space my-space my-unit -o jq='.Unit.NeededPaths'

That is how you check what ConfigHub worked out for a Unit before wiring anything up — including which needed paths are still unmatched.

A match between a needed value and a provided one is recorded as a Binding on the NeedsProvides Link. Resolving the Link — automatically, or on demand — stores one Binding per pair it matched, each naming the ProvidedResource and ProvidedPath it read from, the NeededResource and NeededPath it wrote to, and the DataType.

So the Unit fields say what was identified and the Link's Bindings say what was wired. Bindings can also be written by hand, with AutoUpdate false, to propagate a value to or from a location the automatic matching does not cover.

See managing dependencies for the commands.

Extending what is identified

The built-in function executor identifies these attributes for the resource types it knows. To add your own, define an Attribute in the Space: it registers get-<slug> and set-<slug> functions over the resource type paths you name, and a path entry marked IsNeeded participates in needs/provides resolution like any built-in one.

Currently needed values are indicated by the presence of placeholder values.