As of Juju 2.8, controllers now have the ability to store state on a charm’s behalf via three new hook tools:
As with other hook tools, the
state-* family uses a simple key/value API:
state-set <key> <value>:
state-get <key>: retrieve the value of
state-delete: delete a key
Charms are an implementation of the “Operator Pattern”. This means that Juju uses active software agents—visible as
jujud processes—to execute charms. Charms, especially those written with the Operator Framework and the Reactive Framework, require the ability to record their current progress on disk.
Making changes to a machine’s local disk can cause problems over time, especially when applications are co-located.
This has inhibited k8s charms on Kubernetes clusters without storage volumes.
A “Stateless Application” is one that can operate without local persistent storage. They’re typically used in a microservices architecture and are excellent candidates for horizontal scaling.
This feature is available to charms, and is not directly usable by people deploying charms.
To ensure that charms are deployed to models which support this feature, add a requirement within the charm’s
For charms that also wish to be able to be deployed with pre-2.8 models, then they should emulate the behaviour by writing to the charm directory. The
StoredState class within the operator framework demonstrates leveraging SQLite for this.