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.
@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.
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.