‘Reactive’ vs ‘Hooks’


This discussion is proposed to clarify the short-comings and misunderstandings in reative programming and hooks.
what is reactive programming?
What are hooks?
why we need these two?
How relations are made using hooks?
Why these relations are necessary in charm deveoplment?
why it’s necessary to create reactive programming?
How effectively we can make our custom charm using reactive programming and defining hooks (and their relations)?


@erik-lonroth i would like you to share your knowledge related to these here.
it’ll be great discussion,hopefully.


Hey munir12!

Reactive programming means using the reactive framework to write charms. That framework is a helper to write better charms (reusable, cleaner) in a quicker way (stop re-inventing the wheel). Vision of reactive programming can be found at:

Hooks are the way Juju communicates with the deployed applications (copies of a charm code). When they get deployed, their config changed, or a relation to another application is added, Juju will run a hook, which is no more than a script under the hook name ($CHARM_DIR/hooks/install, config-changed, etc.). Please check:

Relations are important when you need to share information to configure a couple of applications. Instead of hard-coding the config of one of the applications into the other, “juju add-relation” makes it possible to automatically configure client/server applications. There are tools included on deployed units of each application to gather/share data through relations (relation-set, relation-get).

Please check the following link to start writing charms:

Hope this helps.



Just to add more of a distinction between hooks vs reactive code. Juju has specific domain events that occur and you can write a script of any language in your charm to process/run when that occurs. So there’s an install hook, a onfig-changed hook, etc. These are the bare bone underpinning layers of writing charms. Folks have written those hooks in ruby, go, bash, and python.

Reactive is a bit of an opinionated framework that helps make writing charms easier to think about and process. It includes some charm specific state information and thinks less about the Juju events, but allows charm authors to set flags around the charm’s own events. In this way you can say “when package x is installed, do this” or “when this config changes do that” or “when I’ve reached solid HA run this code”. It’s moves the domain knowledge up another level from Juju to specifics around the charm.

The reactive framework is written using Python and it setups up the hook scripts such that when Juju has event changes the reactive flags state is checked and new events can be defined and triggered by the charm author. So we find that writing solid charms works a bit better up here.

There’s also some standards for including libraries in reactive. Nearly all charms need to install packages from apt or from the snapstore so there are layers (apt/snap) that anyone writing a reactive charm can include that helps provide some of the standard tooling like, checking if there’s any proxies that need to be handled, or other standard behavior so you don’t have to rewrite it each time you write a charm.

Again, the framework is on top of the base Juju hooks and just makes it easier (the more complex the charm the more it helps) to build a really solid charm.



thank you for your response @rick_h
is it possible for your to guide me on scaling & healing stuff that how can we scale-up or scale down, how to heal the bugs/errors automatically through juju charms?