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 :
resources:
mysql_image:
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
{
"RegistryPath":"testing@sha256:beef-deed",
"Username":"docker-registry",
"Password":"fragglerock"
}
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