klippy

Overview

klippy is a controller that proposes creating packages as a child of a parent package, where all the bindings can be satisfied.

The idea is that packages in this "proposed by robot" state can provide a guided authoring experience, and we can communicate these paths through the existing API.

The controller and the idea of package proposals should be considered exploration / experimental.

Bindings

The idea of bindings is that a blueprint author can include some objects that are specially marked with the config.kubernetes.io/local-config = binding annotation. Those are binding objects.

Because those binding objects are local-config, they will not be applied to the cluster as part of the package. Instead, those objects normally come from a parent package.

The value of a binding object comes when we replace the placeholder values with the actual values from the parent. We do a semantically aware rename, so - for example - if a binding objects is a namespace, all the objects in the binding placeholder namespace would be changed to be in the newly bound namespace.

If the object is something like a ConfigMap, we would update all the references to that ConfigMap, for example in pod volumes.

klippy: auto-binding

The idea of the klippy controller therefore is to eagerly look for places where we can instantiate a child package under a parent package, where all the bindings can be satisfied.

We match bindings based on the Group/Version/Kind. Additionally, if the binding object has labels, we'll look for those labels on the parent package object (this was needed because otherwise we were over-proposing on common objects like Namespaces, in practice we need some sort of "intent" label on Namespaces or GCP Projects/Folders, that indicates what we expect them to contain)