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
sdf3f2
Now, only after UPLOADING the charm to charmhub.io (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?
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.
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
applications:
mongodb:
charm: mongodb
series: focal
os: ubuntu
charm-origin: charmhub
charm-name: mongodb
charm-rev: 60
charm-channel: stable
charm-version: 5046c89
exposed: false
application-status:
current: active
message: Unit is ready
since: 19 Aug 2021 15:06:23-03:00
relations:
database:
- graylog
replica-set:
- mongodb
units:
mongodb/0:
workload-status:
current: active
message: Unit is ready
since: 19 Aug 2021 15:06:23-03:00
juju-status:
current: idle
since: 23 Aug 2021 10:54:00-03:00
version: 2.9.11
leader: true
machine: "5"
open-ports:
- 27017/tcp
- 27019/tcp
- 27021/tcp
- 28017/tcp
public-address: 10.220.130.118
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.
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.