abstraktor

Low-touch platform abstractions for Kubernetes using cuelang

How it works

Abstraktor uses cue, a non-Turing complete configuration language designed to eliminate a set of failure cases common to configuration languages. This is achieved through the use of a value lattice - a type hierarchy in which typed values can be specified as abstract or concrete, but can never be set to conflicting values. This allows for expressive constraints without the possibility of contradictory conditions on data.

Abstraktor defines schema representing the following:

• Fully reified resources (e.g. PubSubSubscription)
• User-facing abstractions (e.g. Queue)
• Transformations from abstraction to reified resource(s)

To actually reify resources, provided configuration is added and all configuration is evaluated, taking only the fully concrete results as output - that is, valid JSON.

The additional configuration can come from multiple sources. For example, the user's specification can be combined with specifications particular to one or more aspects of the evaluation environment to allow for separation of concerns.

Injecting Configuration

The injection of configuration can be achieved multiple ways within cue. At present, it is done manually, by specifying the value input. Transformation schema are defined in terms of this value in order to concretize the output. In future, this will be refined slightly, using cue's built-in scripting layer and/or a harness script/binary to handle the injection of configuration prior to evaluation.

Testing

Before using this approach in production, tests should absolutely be specified for each abstraction. Whether testing is achieved in pure cue or via a harness, authors of new abstractions should be able to add expressive tests alongside their definitions to clearly demonstrate business logic to readers of the code.

In addition to tests defined in cue, integration testing is desirable.

Cue Zen from Defn

Make input a list
Make output a comprehension

TODO

• Rearrange packages in schema folder - tests next to abstraction schema, downstream resources adjacent to abstractions

• Add tests (pure cue? rego? idk)

• Create interface for invoking transformation

  • "Read data in" somehow - a command or a harness

DONE

• Import schema for pubsub config connector resources
• Create transformation for abstraction to config connector resources
  • Assume input data is a static definition in the same scope