Manifest-driven charming (new pattern)

In the end, the output of a charm is a (model-backed, auto-reconciling, continuously updated) nice and cozy environment for a workload to run in. This includes:

  • Files
  • Pebble plan
    • Command(s)
    • Environment variables

So all a charm needs to doTM is take relation data and config options, and use that to gather/build some files and commands to push into a container. Let’s call that a manifest:

Definition: manifest = files + pebble plan

Until now we’ve been mostly doing event-driven charming. It might be interesting to consider a manifest-driven charming.

Summarized in a diagram, it could look like this:

(Note: this PNG has an embedded draw.io diagram you can edit.)

2 Likes

@sed-i, the idea is fascinating. However, it’s a bit hard to tell without a concrete example to look at. Do you think you could work up an example charm that uses this pattern? No need for charm libs / PyPI packages, just a test charm with three files showing the relation manager, config builder, and workload manager would be very helpful.

here it is

Well that looks a bit like what we’re trying to do with the 12-factor project:

  • An init command that adapts to your application and generated a rockcraft.yaml and charmcraft.yaml
  • A charmcraft.yaml that list the relations and configuration options
  • And a set of libraries that brings the logic / event handling / pebble plan

It’s slightly different, but I think the end result is the same. Bring your application, describe want you want, and you get a charm

The alertmanager PR that Pietro linked is splitting into config builder and workload manager, but we didn’t go all-in on the “manifest driven” part yet.

Also, with the config builder, there is tension between just being a yaml builder vs. juju-aware.

I will try to come up with a good example soon.

Here’s a modest start: https://github.com/sed-i/flog-k8s-operator/pull/1

1 Like