Revision vs version

Having some problems understanding how to “version/revision” my charms. Hope to get some input.

I’m currently injecting some of my charms with a custom file “version” which contains the commit-hash from github.

This an excerpt from how it looks in my Makefile

.PHONY: version
version: ## Generate version file
@git describe --tags --dirty --always > grafana/version
@echo Building version: `cat grafana/version`

This file is thus included in the charm I build.

make build

The content is a commit hash, for example:

$ cat version

Now, only after UPLOADING the charm to (charmcraft upload/release), it seems that charmhub injects a new file into the charm: “revision”. This file is NOT included by me as a charmer.

My question is about if it is possible to connect the revision file to my custom version file, such that I can link my code to the running version of a charm and have that displayed properly by juju status?

@heitor @jamesbeedy @joakimnyman @hallback @emcp

1 Like

Revision an the integer which is incremented each time the charm is updated in charnhub. It’s used to track whether a deployed charm is out of date with upstream - Juju will periodically check the deployed revision in the model against what the latest published revision is in the store and report via status if a charmhub update is available.

The version, as indicated by your Makefile target, is VCS sha representing the source from which the charm was packaged. This is actually shown is juju status as “charm-version” if you print YAML or JSON - it doesn’t show in tabular status output.

There does appear maybe there’s a charmcraft bug here. The older “charm build” tool for reactive charms automatically generated the version file if the charm was being built from the root directory of a VCS checkout (git or bzr or hg). There’s no need for any Makefile involvement.

I just checked a packaged charmhub charm built using charmcraft and there’s no version file there so that will need to be fixed.


This is great!

$ juju status --format yaml | grep charm-version
    charm-version: 93f9566
    charm-version: d341ec7
    charm-version: "1061146"

This was really new to me!

The “version” file would be good to add some information about since its critical to the CI/CD workflows. It might be there already…

This is probably very interesting to @heitor @jamesbeedy @joakimnyman @emcp @bissane

We have been populating the version file for our slurm charms, for it to appear in Charmhub dropdown menu and in juju status. The filename must be all lowercase.

Now I am very confused. juju status --format yaml displays two versions for each Juju Application, version and charm-version:

$ juju status mongodb --format yaml
    charm: mongodb
    series: focal
    os: ubuntu
    charm-origin: charmhub
    charm-name: mongodb
    charm-rev: 60
    charm-channel: stable
    charm-version: 5046c89
    exposed: false
      current: active
      message: Unit is ready
      since: 19 Aug 2021 15:06:23-03:00
      - graylog
      - mongodb
          current: active
          message: Unit is ready
          since: 19 Aug 2021 15:06:23-03:00
          current: idle
          since: 23 Aug 2021 10:54:00-03:00
          version: 2.9.11
        leader: true
        machine: "5"
        - 27017/tcp
        - 27019/tcp
        - 27021/tcp
        - 28017/tcp
    version: 3.6.8

(some lines removed for brevity)

So, juju status shows the charm revision, that is just the number of charms uploaded to CharmHub, prior to that charm; the application’s version is actually the unit’s underlying workload version; and the charm-version is an Easter-egg that actually documents the charm code version.

How could we improve this?

1 Like

I would say that consistency in terminology is very needed here since this is confusing on every possible level. The term: “version” is ambiguous on pretty much every aspect.

“workload-” version
“application-” version
“series-” version
“charm-” version
“juju-” version

… and so on.

All these multi-named terms causes massive confusion and that propagates fast to underlying functions, code and docs.

Consistant naming of all the stuff into a set of well defined terminologies is the improvement needed.

Yeah, so many entities in the stack can be versioned as you have enumerated.

This is definitely a candidate for better documentation which we’ll aim to address.