[community workshop] Charming fundamentals



Charming isn’t easy, especially if you have no idea what Juju is. And if you don’t know what Juju is, maybe you should try it out. To level the playing field, we’re going to assume the following:

  • rough juju sdk understanding
  • access to an environment with ubuntu + microk8s (you can use a multipass VM to get there)
    • see Jose’s charm-dev-utils for an amazing script to set it all quickly up
  • have charmcraft, juju and jhack snaps installed
  • have a bootstrapped juju controller on microk8s (or other k8s)

See also:


We will go through writing a simple charm and discuss some tips, tricks, and touch upon some best practices and gotcha’s. Topics will include:

  • Bootstrapping a charm repository
  • The charm construct and ops model
  • Breaking down the task of writing a charm:
    • Workload installation
    • Workload configuration
    • Workload operation

The workshop will be recorded and posted publicly for those who were unable to attend in person.

Recording is available here.


This is great! I will be there and try to funnel in some other dev-ops:es!

1 Like

I was only able to make part of this. Where is the video posted?

Hi @codersquid I have the recording, I’ll need to edit it a little bit and cut out the parts where I rambled a bit too much, and then I’ll have it published on canonical’s youtube channel. Will add a link to this post when that’s done, I’d expect it to be ready by end of next week. I’m off until Tuesday.


I believe this is the video: Introduction to charming | Juju Community workshop 25 May 2023 - YouTube

1 Like

thanks! I wasn’t informed that it was live :slight_smile:

1 Like

You’re welcome.

You elude to there being parts 2 and 3 at some future time.

Was this statement hypothetical or do you have plans to continue the introductory presentations to cover other life-cycle events; up to tear down?

Also, I assume the config related code output the Grafana Tempo config as a JSON as that’s what the Grafana Tempo binary expects; but you could equally have output YAML or passed the config as environment variables depending on what the charm’ed container can handle.

Finally… and sorry if this is not the appropriate place to ask; but it appears that Juju Container Layers are akin to Docker image layers where the final Docker image is normally comprised of successive overlays.

parts 2 and 3 are so far a hopeful thought, but I’d like to have them. Stay tuned :slight_smile:

Yes: the tempo container expects a yaml config file, but if all your application takes is envvars, that’s also an option. It all depends indeed on what the charm’ed container wants.

I think I can see the analogy between pebble layers and container layers, but I’m not sure if they have a shared history. Maybe @benhoyt has some insights into how the design came to be and what the driving metaphor was?

1 Like

Yeah, Pebble configuration layers are analogous to layers in a Docker image. They’re somewhat different, as config is not an “image”, but it’s definitely a good analogy. And – though I wasn’t involved in Pebble at the start when “layers” were added – I believe since then Gustavo has mentioned that was why the terminology was chosen, to remind us of layers in a Docker image.

1 Like