What is a charm?

Дата публикации: 23-09-2026 08:37:13

What is a charm?
[CAUTION]
This is a haphazard collection of thoughts and feelings and any meaningful conclusion will have to come from you - much like therapy
Earlier this year I attended Current 2026, a convention organised by Confluent, focused on data streaming tech like Kafka and Flink. Despite being doubly a leper in the eyes of most of the sales reps - by virtue of being an engineer and an open-source one at that (i.e. won’t buy their SaaS ) - I had a great opportunity to chat to some FOSSy folks working with the very popular CNCF Incubating project Strimzi Kafka operator. While diligently proselytising the Church of Juju and our own Charmed Apache Kafka, some of the people there wanted to better understand how Canonical’s charmed operators compared to the CRD-focused Operator Framework solutions they were familiar with, and especially what problems they are trying to solve.
Now, I’ve spent the last 5 years developing, deploying and operating charms, and all charmers sleep more soundly at night, comforted by the knowledge that we (probably) grasp the essence of what we do. OK then, easy - deep breath:
I described the charms as Python scripts that are executed as handlers for an event-queue coordinated by a controller called Juju. I talked about how they work on not just Kubernetes but also bare-metal and clouds. I talked about Canonical’s operator repertoire being distributed and available through something called Charmhub. I said all the best words in the best order like “deploy”, “configure”, “scale”, “manage” and even “integrate”! I talked about bootstrapping and units and applications and config-changed events and refreshes and relation data and dqlite. I talked about snaps and rocks and security maintenance. I talked about interfaces and relations and how charms are meant to connect with other charms, and so on and so on and so on and…
Charms need a mission statement
Canonical as an org has an excellent one - “To bring free software to the widest audience”. Punchy, clear and direct. When talking to the community about charms however, there needs to be a similarly clear and direct vision to share as to what exactly justifies the existence of charms amongst an already established operator ecosystem, what concrete and very human problems they solve, and most importantly what design and service principles can the community depend on from charmed operators. The principles of this mission need to be readily self-evident in the products distributed on the storefront, with a consistent identity and purpose.
The core of the issue to me, is that while a lot of the over-eager word-spaghetti I burdened innocent conference-goers (and now also you) with above aligns well with what a “software operator” is in theory, it doesn’t capture the actual gestalt of what a Juju “charm” actually is or what they’re for. Our own documentation is also very vague about this, when taken directly from the Juju docs:
In Juju, a charm is an operator – software that wraps an application and that
contains all of the instructions necessary for deploying, configuring, scaling,
integrating, etc., the application on any Juju-supported cloud.
Charms are often published on Charmhub.
This covers all the main points, it’s software, it’s a way of packaging FOSS, it does operational things, there’s a store (probably) etc, but I would like to make the case that this mental model is not enough in helping steer us as engineers in making better and more consistent products for the ecosystem and for users. It is purely functional, but not essential, and provides us little in helping us prioritise which features, refactors, stabilizations or UX changes are needed in order to make our products excellent.
We need a clear statement for charms that we bring up in discussions, evaluate each other’s code against, and push back to PMs with.
Conflicting focuses
Charms have been around for a while now, and - much like humans - are often inconsistent in their adherence to a nebulous and loosely defined picture of “quality”. I can think of several initiatives across the org that endeavor to help this:
The Charm Tech team has done great work of standardising charms’ public listings on Charmhub with the canonical/charmhub-listing-review processes
The Managed Solutions team have meticulously defined metrics for their Operational Readiness Scores for helping steer product design decisions by looking at operational capabilities of charms
Field Engineering with SolQA have worked on defining how to construct a charmed product vs a reference architecture and how to test them in Terragrunt Units and Stacks
(I’m sure there are many more that I’m either not aware of or have bluntly forgotten about. Do let me know and I’ll add them above).
These initiatives - in my view - are all attempting to slay the same dragon in their own way, satisfactorily answering the question of what is a charm?, and measurably answering is this charm ready to join the others?.
The charming ecosystem is often anything but consistent and harmonious, and while it’s easier to say this is the fault of people or process, it seems more likely that it’s a symptom of a need for a clear vision, one that we can share with the community, and point to during development as a compass points to magnetic north. Currently within the charming world, I see three subtly different narratives of what any single charmed operator or solution is and needs to be currently in play:
A building-block of a broader ‘build your own cloud’ ecosystem of software with seamless integrations - OpenStack charms focus here
A security maintained, stand-alone package with highly-opinionated operational abstractions and configuration settings for popular software - the Data Platform and Analytics charms are good examples
An internal component of broader Canonical solutions for best-in-class systems for common architectures - COS and Identity Platform both prioritise this
Often, these focuses conflict with one-another, leading to discordance in Charmhub listings, non-backwards-compatible interfaces, gaps in operational capabilities, user-interfaces and general functionality. Going further, it makes collaboration between charm teams even more challenging, as quite often the efforts of one focus are of minimal interest to the others, fragmenting the ecosystem more.
Butlers of the family estate
As mentioned in CAUTION at the very start, I don’t have a fulfilling answer to this question, but despite this I would like to try and aid in self-actualisation for the charming world, in the hope that this might help someone in day-to-day design decisions.
Following is a loose collection of standards I try my best to follow when deciding where to go next for our charms, told through an analogy of a good butler (charms) and staff (workload/Juju/infra) for an aristocratic family (users) on a grand estate - an image I do hope translates to those outside of the UK.
A good butler acts as a bridge between the aristocratic family upstairs and the chaotic downstairs staff. They ensure that never the two should meet, shielding the family from the frantic effort required in running the house, projecting only serene and invisible control and seemingly blending in to the background.
Whether they are overseeing an annual formal party of 50, or a quiet meal for the family, a good butler will never panic or show stress, and always knows precisely how to announce and seat the guests for any formal occasion.
A butler must never be seen serving food directly to the family unless it is a matter of high distinction, but must instead stand vigilantly behind the downstairs staff, monitoring the pacing of the meal and managing the standard of service with deftness and poise.
They are the trusted guardians of the wealth of the family’s estate, treating the duty of protecting the keys to the wine cellar and silver pantry and fine china with the utmost importance, keeping meticulous logs and ledgers.
A good butler is discreet, showing unwavering discretion about the family scandals, debts and private lives. A good butler protects the reputation of the family with infallible loyalty, treating estate matters as sacrosanct, knowing that a single mistake might be considered a profound insult to guests and a failure of the house.
Above all, they are also expert sommeliers and have encyclopedic knowledge of etiquette and protocol, setting the tone for formality and decorum by selecting only the most appropriate wines to pair with a meal. They anticipate family needs before they are spoken, and always with exceptional taste. In turn, a good butler never oversteps their position in presuming when not appropriate, responding to family requests promptly and with supreme confidence.
If our charms could be even half as good as a good butler, I think we’d be on the right track.
1 post - 1 participant
Read full topic

Схожие новости

#	Наименование новости	Тональность	Информативность	Дата публикации
1	Canonical Academy beta is open	0	9.6	15-09-2026
2	Upgrades from Ubuntu 24.04 LTS to Ubuntu 26.04.1 LTS now enabled	0	10.5	29-09-2026
3	Ubuntu 26.10 (Stonking Stingray) Beta released	0	8.78	01-10-2026
4	Открываем код YTsaurus Flow: как обрабатывать более 100 ГБ/с в реальном времени без потерь и дублей	0	7.54	06-10-2026
5	Understanding Kubernetes Operators: A Beginner’s Guide	0	7.46	04-07-2026
6	A Beginner’s Guide to Kubernetes Operators and How They Work	0	8.1	27-09-2026
7	"Module: A Reusable State-Machine Framework for NFT Capabilities (Ownership Module v0.5 → v1.0)"	0	12.53	27-09-2026
8	Comparing Open Source LLMs in 2026: Llama 3, Mistral, and Gemma	0	17.09	15-09-2026
9	65 бесплатных уроков октября: от LLM и Kubernetes до микросервисов, Kafka и безопасности	0	11.95	01-10-2026
10	Daily Hacker News for 2026-09-27	0	9.43	28-09-2026

Классификация: . Схожих патентов: 0. Схожих новостей: 10. Тональность: 0. Информативность: 8.06. Источник: discourse.ubuntu.com.