This extends the Critical Review of Juju Today post that I previously made and expands on the final notes about using an Actor model for writing charms.
At this point, we at Katharos Technology are going to pursue building an Actor-based charming framework that takes a more drastic approach than Lucky to changing the way that charms are written.
Where Lucky was designed to be fully compatible with the existing Juju charming system, i.e. you could not tell the difference between a Lucky charm and a reactive/bash charm when you deployed it, the Actor framework will take the approach of trying to re-model how charms relate to each-other, creating a new class of Juju charms that are only compatible with other Actor charms.
This obviously has the disadvantage of potentially dividing the community because of the incompatibility of Actor and other charms, and this has not been taken lightly. Still, we have found there to be certain limitations in the current design ( covered in the post linked above ) that cannot be changed while staying compatible with the existing charming system.
Semi-Quick Breakdown
This is the somewhat abbreviated description of the idea for the Actor framework design. We are going to create a more formalized design document later.
Refactoring Relations
The Actor framework, in order to break out of the limitations of the hook life-cycle today’s charms are restricted to, will hijack the Juju agent that is deployed with charms and take the task of communicating with the Juju server on itself. This will free the framework to initiate charm logic and communication whenever it chooses.
The Actor framework will use the existing charm relation system to share the IP and port that the Actor framework listens on and it will use that to establish a TCP connection with all of the other charms that the current charm is related to. The charm will use that TCP connection to join the Actor system cluster at which point it is free to send arbitrary messages to all of the other Actor charms that are related to it.
Instead of sharing key-value pairs over relations, actors will mange their own state internally and send messages containing key-value or JSON data to the other related charms.
Language Agnostic
Actor’s should be able to be written in any language. Bash and Python will be top targets for specifically promoted languages.
Because actors only interact by sending messages, all actors will be compatible with all other actors regardless of the language they are written in.
Sub Actors
There will also be the ability to write sub-actors that are simply actors that run on the same machine and are child actors of a deployed charm. These sub-actors will act as modules that can be downloaded from the Actor Store and used to encapsulate logic common to different charms.
This is conceptually similar to Reactive layers, but they will be language agnostic as all communication with the sub-actor’s will happen over the language agnostic message interface.
This would replace the hard-coded Docker integration that exists with Lucky as Docker support could be integrated as a sub-actor that presents a message interface for running Docker containers.
Typed Interfaces
Interfaces between actors ( and therefore charms ) will use a type-checked schema to verify compatibility. These schemas will be pushed to the Actor store where the can be centrally managed to unify the community’s schema definitions.
Actor Store
The actor store will allow you to push your charms, interfaces, and sub-actors to a centralized repository. Charms, interfaces, and sub-actors will use Semantic versioning and can be downloaded with the juju actor plugin.
It should still be possible to deploy Actor charms from the main Juju store, but there may be advantages to having its own store that can be integrated with the sub-actor and interface repository also hosted by the Actor store.
juju actor Plugin
The Actor framework may come with a Juju plugin that can be used to deploy Actor charms from the Actor store. This plugin may serve as the primary Actor framework CLI as well ( not sure yet ).
The Actor framework CLI will come with the tools to push and pull Charms, sub-actors, and interfaces from the Actor store as well as building your actor charms and other related tasks.
Summary
We think that, without changing Juju core, there is still the possibility to achieve a drastically new charm development experience that has advantages over the way charms are developed today and can hopefully help developers write more reliable and easier to understand charms.