Application Version in `juju status`

charm
1

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
2

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.

3

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:

4

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.

5

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
6

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: )?

7

Sorry for the late reply.
We had already improved the app version after rc12 and prior to the final 2.9.0 release.

As of Juju 2.9.0, the postgresql-k8s example now shows

App             Version                  Status   Scale  Charm           Store     Channel  Rev 
postgresql-k8s  stubcan/pgcharm@fc85444  waiting      1  postgresql-k8s  charmhub  stable     2

Note the abbreviated sha to provide visibility when the image is updated.
As you note, --format yaml shows the full image URL.

8

Yeah, thatā€™s a nice improvement, thx!