Kubernetes charms (v1) - workload images

There’s been a few questions recently on how charms specify the OCI image they want to use for the workload.

There’s a Kubernetes charm tutorial which explains how (v1) Kubernetes charms are constructed. The relevant information is that the charm includes a resource of type ‘oci-image’ in its metadata.yaml, eg :

    type: oci-image
    description: Image used for mariadb pod.

A charm and its OCI image are published to the store using the charm tool.

What actually happens is that the OCI image is uploaded to an image repository hosted by the store. The charm resource gets a JSON snippet which describes the hosted image, eg


When the charm is deployed, Juju does not download the actual OCI image. It fetches the stored resource which is the JSON snippet described above and uses this info to set up the Kubernetes pod spec image metadata; it’s Kubernetes which actually pulls the image from the specified registry path. Public images do not use a username or password.

For dev/test, you may want to use a different image to the one published with the charm. And for local charms, there is no published image so the follow applies in that case also. You deploy the charm and use the --resource argument to specify the image path, eg

juju deploy cs:~juju/mariadb-k8s --resource mysql_image=mariadb:latest
juju deploy /path/to/mariadb-k8s --resource mysql_image=mariadb:latest

When upgrading a charm, --resource can also be used to specify a different workload image, eg

juju upgrade-charm mariadb-k8s --resource mysql_image=mariadb:9.0

Could you clarify this a bit? I’m testing this out with openldap | Juju and am using a public image, in this case openldapcharmers/openldap:2.4.50. However, this seems to be using a username and password when pulling from the charmstore registry. I did the following, per the “Example workflow” on https://juju.is/docs/charm-writing/kubernetes:

charm push . cs:~mthaddon/openldap
docker pull openldapcharmers/openldap:2.4.50
charm attach cs:~mthaddon/openldap-4 openldap-image=openldapcharmers/openldap:2.4.50
charm release cs:~mthaddon/openldap-4 --resource openldap-image-2

Is there some other way I should be specifying things that would mark the image as public, or do you mean that when you specify --resource=openldapcharmers/openldap:2.4.50 that would be using the public image, but all images on the charmstore will be using a username and password for that registry?

Yes, images uploaded to the charmstore repository are not public - they use a macaroon to authorise access. The attach process uploads the image and mints a macaroon which is added to the JSON metadata snippet stored as the charm resource content.

Thanks, we’ve now implemented this for the OpenLDAP charm.

One thing that does stand out to me is that juju deploy cs:~openldap-charmers/openldap gets us a “version” in juju status of:


Whereas juju deploy cs:~openldap-charmers/openldap --resource openldap-mage=openldapcharmers/openldap:2.4.50 gets you a “version” in juju status of:


They’re both using the same image underneath, but the deployment with a custom resource seems like a more user-friendly output in this case.

Yeah, long image paths are an issue - truncating just the right way for user friendly display in tabular status needs some work. Displaying just the image name without the path / repo is ambiguous but maybe that’s ok for tabular if yaml/json show the full path.

Yeah, I think the difficult thing is what to truncate it to. The full URL is (from juju status --format yaml):


I’m not sure what you could truncate this to that would be end-user friendly, as it seems designed more from the perspective of making it easy for charm authors to verify specifically what image is being used.