Charm

[tmihoc (Teodora Mihoc)]

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 cloud using Juju.

See more: SDK | List of files in the charm project, SDK | The Juju execution flow for a charm

Charms are publicly available on Charmhub.

Charms are currently of two kinds, depending on the target deployment substrate:

1. Machine charms: Charms made to deploy on a bare-metal server, virtual machine, or system container.
   • Charmhub | Machine charms
2. Kubernetes charms: Charms built to deploy on Kubernetes.
   • Charmhub | Kubernetes charms
     • Charmhub | example Kubernetes charm: PostgreSQL K8s

Charms are currently developed using Charmcraft and Ops.

See more: SDK Juju | Charm taxonomy , SDK Juju | Charms vs. Kubernetes operators

While the quality of individual charms may vary, charms are intended to implement a general and comprehensive approach for operating applications.

See more: SDK | Charm maturity

[cory_fu (Cory Johns)]

I think the description of a charmed operator here is a bit oversimplified. The description in the SDK docs goes into more details and gives a better idea of why a charm is more than just, say, an Ansible Playbook or Helm chart. At the very least, I think it would be good to link to that other doc.

[tmihoc (Teodora Mihoc)]

Thanks for your input, @cory_fu . This text is actually not new—it used to be a section under OLM docs >> Concepts, but I thought it didn’t have sufficient visibility there, so I pulled it out into a separate doc, so what you’re seeing here is simply the result of that. I think it’s fine for us to have two docs on this, one in the OLM docs, targeted at an OLM end user, and one in the SDK docs, targeted at a charm author. But I agree with you that the two perspectives should be connected, not just for this concept but indeed for a lot of other concepts too. (For example, for the notion of storage, we again have an OLM perspective and an SDK perspective, and there too the reader might benefit if we connected the two.) I think I’ll just include a link to that to the SDK docs for now, as you suggest. Thanks again!