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:
https://github.com/juju-solutions/charms.reactive/blob/master/VISION.md
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.
Cheers,
-Alvaro.
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.
HTH
2 Likes
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?
In response to @munir12 I’ve opened up a discussion as a prelude to a tutorial around hooks here: https://discourse.jujucharms.com/t/charm-problems-with-bash-hooks/1229
I’d love to work with you in that thread to produce an intro to “hooks” for juju to go alongside the reactive tutorial series already written here: https://discourse.jujucharms.com/t/tutorial-charm-development-beginner-part-1/377/35
2 Likes
I’ve explored another path here, which might be “better” . I took inspiration from the “ubuntu lite” charm and assembled a python version instead.
Here it is: https://jujucharms.com/new/u/erik-lonroth/tiny-python
… and an exact replica for bash here: https://jujucharms.com/new/u/erik-lonroth/tiny-bash
This is perhaps a better way to introduce beginners to hooks? It picks a somewhat intermediate way - leaving out “bash” from the picture. I think perhaps its a bad idea to introduce bash as a path in the learning process. I think its better to consistently use python.
However - the “python path” to charming the way this charm is quite messy. (Just look at the “setup.py” !) Its also not very “general” in its approach as I would like to stay on a more OS agnostic path, not getting to specific to Ubuntu at this stage. Not sure if that is possible or not…
OS agnostic doesn’t really work for charms because they are inherently “configure the OS to bring up an application”. They are the glue between the application and the OS. And you can do things like “install via yum vs apt”, but things that do that are going to be just as clumsy in bash as they are in python.
Its actually for this reason that Juju charms are restricted by OS, because all the interesting things that a charm has to do are pretty much OS specific. You can write an OS abstraction layer, but the name of the packages, the specifics of where configuration sits, etc mean that you end up abstracting a lot. And it seems like it could be better to put the shared code into something like a layer, and the charm specific stuff is the OS specific stuff.
2 Likes
Very interesting thoughts although I think that the very basic/core functionality should be tried to be kept down to core linux (distro agnostic) as this at least helps opening up for charming to more than ubuntu/deb systems.
I have watched a few promotional videos about Juju and also heared the marketing material for juju, at least a few of them put forward this attribute. Its been somewhat of a disapointment for me at least to discover that juju has so many problems with other OS:es (not ubuntu) that serverely weakens the case for juju. I don’t have any experience with other similar toosl, but I would be very curious about how for example Terraforms handles this.
Anyway, thanx for your great input - I learned from that.
1 Like