Respect charm revision in air-gapped environment

[Alex Lutay]

Hi,

It is a copy of request from MM:
https://chat.charmhub.io/charmhub/pl/46woqta5b7ghipnu8d39khdbwo

At the moment, the air-gapped deployments happens in way:

> juju download mysql --channel 8.0/edge
Fetching charm "mysql" revision 188 using "8.0/edge" channel and base "amd64/ubuntu/22.04"
Install the "mysql" charm with:
    juju deploy ./mysql_r188.charm

> ls *.charm
mysql_r183.charm mysql_r188.charm postgresql-k8s_r73.charm

> juju deploy ./mysql_r188.charm
Located local charm "mysql", revision 0
Deploying "mysql" from local charm "mysql", revision 0 on ubuntu@22.04/stable

As you can see the revision got dropped from "188" to "0".
It creates a lot of confusion and unnecessary complexity on upgrades.

Goal: invent possibility to deploy juju charms into air-gapped installations holing the charmhub revisions.

P.S. It is already avaiable for SNAPs as store has a concept of ".asserts".
Assert file is downloaded together with .snap file:

https://ubuntu.com/core/docs/reference/assertions/snap-declaration

> snap download charmed-mysql --edge
Fetching snap "charmed-mysql"
Fetching assertions for "charmed-mysql"
ls Install the snap with:
   snap ack charmed-mysql_69.assert
   snap install charmed-mysql_69.snap

> ls -la
-rw-rw-r-- 1 ubuntu ubuntu 5635 Sep 5 13:24 charmed-mysql_69.assert
-rw------- 1 ubuntu ubuntu 111820800 Sep 5 13:24 charmed-mysql_69.snap

> grep revision charmed-mysql_69.assert
snap-revision: 69

Unfortunately .assert concept is missing for charmhub.io currently.
I hope, it can be included in the nearest roadmap.
Thank you!

[John A Meinel (jameinel)]

As far as specifics, juju is actually respecting the value that is written to the 'revision' file in the charm. If you "unzip mysql_r188.charm" I'm pretty sure you'll find that:
```
$ cat revision
0
```

[Carl Csaposs (carlcsaposs)]

mysql_r188.charm does not contain a `revision` file

If you deploy a charm via Charmhub (e.g. `juju deploy mysql --channel 8.0/edge`) the revision file at /var/lib/juju/agents/unit-mysql-0/charm/revision contains `0`, even though juju status shows `193` as the revision for the `mysql` app

[Alex Lutay (taurus)]

I confirm, the "revision" files inside the "mysql_r188.charm" is "0".
It is actually zero inside all charms I have checked, constantly.

John, please correct my investigation:
 * long-long time ago Juju was generating both "version" (Git hash) and "revision". [1]
 * during migration to charmcraft, that functionality got lost. [2]

Your position: charmcraft/charmhub should generate file "revision" properly (non-zero). Correct?

[1]
https://github.com/juju/charm/blob/master/charmdir.go#L258C1-L260C3
https://github.com/juju/charm/blob/5fe646695e8585e7a6b9fedb0d10cc7fbc598e48/charmdir.go#L521
https://github.com/juju/charm/blob/master/charmbase.go#L66-L72

[2] https://github.com/canonical/charmcraft/issues/37

[Pedro Guimarães (pguimaraes)]

Hi team,

I think we can close this issue as the problem is not in Juju.

As @jameinel pointed out, I can confirm Juju respects the "revision" file. However, charmcraft does not.

If we add a "revision" file in the folder and build it with charmcraft, that file will not be added to the final charm.

Reading through @taurus bug, I can see there is an ongoing discussion about charmcraft / charmhub.

The only remark I have for Juju team is that we have no similar mechanism to set the "channel" information. I will file a new bug to discuss this topic.

[Carl Csaposs (carlcsaposs)]

It still seems like a juju bug to me—I would expect `juju download` and `juju deploy` to use/modify the `revision` file in the same way, so that if I `juju deploy` a charm I downloaded with `juju download` it's the same as if I `juju deploy`ed it from Charmhub directly

[John A Meinel (jameinel)]

Charmstore used to generate the .zip that is a charm "on the fly" and would populate it with its revision information.
It is not possible to populate that value without the stores knowledge (because charmcraft itself doesn't know when you are going to upload the charm, or whether someone else will upload a revision of the charm before you.)

Snapstore/charmhub do not like the idea of on-the-fly editing the content that was uploaded. They want the bits that you had them to be exactly the bits that you get back. So 'revision' is conceptually not palatable (the only one that can know it is charmhub, and they don't want to populate it).
Similarly `juju download` wouldn't be giving you the exact bits that you uploaded, either.

The best workaround that I know of is to populate the `version` file with something like `git describe --tags --dirty > version`.
Charmcraft *will* pack that into the .charm file, and it will show up in `juju status --format=yaml`.

We can discuss a longer term solution involving charm assertions (equivalent of snap assertions) where a separate file is created that ends up signed by the store to indicate extra properties of the snap. But that is not a trivial fix for anyone involved. (you can't just download a single .charm anymore, you have to carry around the assertions and sideload them as you are doing other things, the store needs to be able to produce them, and juju needs to be able to do something with them.)

`version` is at least available today for all products involved. (other than you have to update your build to not *just* be `charmcraft pack`, as you probably don't want to commit your `version` file because once you do, it is immediately out of date.)