Create a minimal Kubernetes charm

Added a note to clarify (a) (local charm). Will look into (b) (how to provide credentials for pulling a container image from a private registry).

Asked around. Long story short: From our point of view, it doesnā€™t make sense to add information about that in the tutorial. The idea is that a charm is made to be published, and then everything about it goes public. For development you can however use a local image, if you wish.

In other words, Juju Charms are not for application development (i.e. deploying application that are developed in-house), is that what youā€™re saying?

The Kubernetes Charms tutorial show-cases a containerized fastapi Python application (it could as well be Django, Flask, RoR or anything else someone would develop a Web application in). How such a charm is deployed is explained in Juju | Create a minimal Kubernetes charm, Validate your Charm. Itā€™s neither obvious nor explained, though, what happens with the image that is passed along to the juju deploy command with the --resource option.

IIUC, the image is uploaded to the Juju controller, which manages a local copy of it. In other words, that explains why you wouldnā€™t use a private container registry for your images, because you upload them directly to your cluster (i.e. the Juju controller).

In my opinion, it would indeed make sense to explain these inner workings in the documentation.

Based on my investigation: No, there is currently not.

The --resource flag accepts 3 types of arguments:

  1. a charm revision number (if the charm is on Charmhub)
  2. a path to a local file
  3. a link to a public OCI image

I will update the docs to make this clearer ā€“ and thanks for bringing it up.

Just a friendly reminder on adding a few words of clarification about what happens to the local charm when itā€™s being deployed (I suppose uploaded and managed by the Juju controller without any reference to an external image registry).

Providing authentication credentials for private OCI registries

As a side note, it should be possible to provide a JSON or YAML file with an image reference and optionally username and password (i.e. an OCI image resource) to allow the Juju controller to pull an image from a private registry.

{
  "ImageName": "my.private.repo.com/a/b:latest",
  "username": "harry",
  "password": "supersecretpassword"
}

or

registrypath: my.private.repo.com/a/b:latest
username: harry
password: supersecretpassword

Thanks @hpidcock for pointing this out on the Charmhub chat!

Hi @bittner, thanks for your input!

I think a note on alternative ways to specify the resource goes beyond the scope of this tutorial (in a tutorial weā€™re allowed to be opinionated and we donā€™t have to cover all the options). However:

I just noticed that the examples donā€™t match: The JSON uses ImageName for the container image reference, while the YAML uses registrypath. Can you double-check with @hpidcock whether both are working examples, or which one is correct? ā€“ I was unable to find matching content in the OCI specification docs.

I wondered about that too. @hpidcock, could you please clarify? Why does the JSON example use ImageName and the YAML registrypath? (Copying the examples below for convenience.)

JSON:

{
  "ImageName": "my.private.repo.com/a/b:latest",
  "username": "harry",
  "password": "supersecretpassword"
}

YAML:

registrypath: my.private.repo.com/a/b:latest
username: harry
password: supersecretpassword

Hi everyone, I noticed that the article frequently mentions ā€œJuju OLMā€. Iā€™ve started reading up on Juju recently and this is the first time I come across the term. Since juju.is/docs/olm now redirects to juju.is/docs/juju, is ā€œJuju OLMā€ now simply referred to as ā€œJujuā€ in the rest of the documentation?

I thought I had replace all instances of ā€œJuju OLMā€ with just ā€œJujuā€. Iā€™ll check again, thanks!

1 Like

Bug: It is impossible to edit this due to mentioning more than 10 people, 11 specifically This locks users out of editing this until one or more members mentioned are removed,

This is inconsistent with the version number we are deploying (1.0.1). There are multiple such inconsistencies throughout the tutorial, I can make suggestions everywhere it happens.

That would be good, thanks! (Weā€™ll collect them and then use them to update both the tutorial and the code repo behind it. Note to self: We need to find a better way to keep these in sync.)

There is also a small bug in the repository that makes it impossible to refresh the deployment (missing an os.pebble.ConnectionError). Iā€™ll suggest all edit so I can do it as part of my onboarding documentation issue.

1 Like