Application Version in `juju status`

One of the key pieces of information for users from juju status is the application version. Taking Mattermost as an example I ran the following to deploy it on a model provisioned in MicroK8s:

juju deploy cs:~mattermost-charmers/mattermost
juju deploy cs:~postgresql-charmers/postgresql-k8s
juju relate mattermost postgresql:db

This gives a juju status that looks something like this:

Model       Controller          Cloud/Region        Version   SLA          Timestamp
mattermost  microk8s-localhost  microk8s/localhost  2.9-rc10  unsupported  09:06:38+02:00

App         Version                         Status  Scale  Charm           Store       Channel  Rev  OS          Address       Message
mattermost  mattermost:v5.33.3-20.04_edge   active      1  mattermost      charmstore  stable    21  kubernetes  10.152.183.7 
postgresql  registry.jujucharms.com/pos...  active      1  postgresql-k8s  charmstore  stable    11  kubernetes 

Unit           Workload  Agent  Address      Ports     Message
mattermost/1*  active    idle   10.1.234.22  8065/TCP  
postgresql/0*  active    idle   10.1.234.20  5432/TCP  Pod configured

Relation provider  Requirer         Interface  Type     Message
postgresql:db      mattermost:db    pgsql      regular
postgresql:peer    postgresql:peer  peer       peer 

It’s very easy to see the version of Mattermost being run from this output (v5.33.3-20.04_edge).

As we move towards the sidecar pattern for charms I’m wondering how we display similar information. I’ve got a proof of concept version of the Mattermost charm using the sidecar pattern, and deployed it locally for testing as follows:

git checkout -b sidecar https://git.launchpad.net/~mthaddon/charm-k8s-mattermost/+git/charm-k8s-mattermost
cd charm-k8s-mattermost
charmcraft build
juju deploy ./mattermost.charm --resource mattermost-image=mattermostcharmers/mattermost:v5.33.3-20.04_edge
juju deploy cs:~postgresql-charmers/postgresql-k8s
juju relate mattermost postgresql:db

Doing that gives me (after a little while) the following from juju status:

Model       Controller          Cloud/Region        Version   SLA          Timestamp
mattermost  microk8s-localhost  microk8s/localhost  2.9-rc10  unsupported  08:51:53+02:00

App         Version                         Status  Scale  Charm           Store       Channel  Rev  OS          Address  Message
mattermost                                  active      1  mattermost      local                  0  ubuntu
postgresql  registry.jujucharms.com/pos...  active      1  postgresql-k8s  charmstore  stable    11  kubernetes

Unit           Workload  Agent  Address      Ports     Message
mattermost/0*  active    idle   10.1.234.18
postgresql/0*  active    idle   10.1.234.20  5432/TCP  Pod configured

Relation provider  Requirer         Interface  Type     Message
postgresql:db      mattermost:db    pgsql      regular
postgresql:peer    postgresql:peer  peer       peer

There are two problems that jump out here. The first one is that the app version for PostgreSQL is reported as registry.jujucharms.com/pos… which is not very user friendly. This is because the charm is configured with a resource for the docker image, and that resource is uploaded to registry.jujucharms.com as part of the publishing process. This isn’t a problem we need to worry about for too long though, because this charm doesn’t use the sidecar pattern, and at some point in the future will be adapted to that.

However, there’s another problem, which is that there’s no app version reported for Mattermost at all. I believe this is something that can be set via charm code, but how can the charm code know what version of Mattermost is running, especially given that someone can change the image resource used at deploy time? Is there a way to query the image for a particular container? I don’t think there is, so I’ve filed https://github.com/canonical/operator/issues/509.

Also, what happens when this is uploaded to charmhub and a resource is attached in terms of the image location and displaying that in a useful way to end users? Currently if I look at the image for postgresql in this model, which uses a resource that was uploaded to the charmstore, I get an image location of registry.jujucharms.com/postgresql-charmers/postgresql-k8s/postgresql-image@sha256:3046a3dc76ee23417f889675bce3a4c08f223b87d1e378eeea3e7490cd27fbc5. How do we translate that into something that’s useful to end users?

2 Likes

There is the juju command available to charmers which is application-version-set. I could see a workaround being to query the API of the application to request it’s version within the charm and for the charm to set the version of the application via this juju agent tool. Obviously, it is not handy for charmers to have to handle this if there is a consistent way this can be queried at the operator framework layer.

We definitely want a human-readable version there, actual docker image hash should likely come in a more detailed output, not the simple status output. I’d prefer this to be blank than useless, and that postgres example is useless :slight_smile:

Agreed on wanting a human-readable version there. In some cases (if your charm is running more than one workload container, or the deployed image isn’t tagged with a useful application version number) the image version/tag isn’t going to provide what you need and charm authors will need to find another way to do this. As @jameinel mentions in https://github.com/canonical/operator/issues/509 this may end up being done by allowing for a way to run an application version command within workload containers.

I do think reporting the docker image URL is probably not the ideal way. It only works when you have short forced versions by the user “juju deploy x --resource foo=postgresql:2.9.2”, or recording that as part of ‘charmcraft upload’.
I think it would be more interesting to have Pebble support interrogating the actual application (rather than the container image), and use:

PG_VERSION=(ask pebble to run 'postgresql --version')
application-version-set $PG_VERSION
2 Likes

Interesting, I’ve just deployed Deploy PostgreSQL using Charmhub - The Open Operator Collection which was uploaded directly to charmhub using the charmcraft tool. Running juju deploy postgresql-k8s on juju 2.9-rc12, and juju status reports the application version as “…”.

Looking in juju status --format yaml I see the more verbose registry.hub.docker.com/stubcan/pgcharm@sha256:fc854442b62e4df279864da48f30a36caca121a5e54d1230301ce6592df5393d. Would it be possible to abbreviate that in juju status to stubcan/pgcharm (we’ll work on moving that to a less user-specific namespace :slight_smile: )?