Charmhub / Charmstore / Project home charm revision confusion

Weird hard question, but how do you tell what version of the charm software you’ll be getting when deploying from the ‘store’

This is currently confusing because both charmhub.io and jaas.ai are live.

Charmhub says use the charm like this: juju deploy *charmname* ,while
Jaas.ai says use it like this: juju deploy *cs:charmname*

That said in each ‘store’ the charm also has a revision, but it doesn’t necessarily mean the code that’s in the store is the latest code from the git repository.
How do these relate and is there visibility on what git commit is related to the published charm revision?

So for Juju 2.9 and above, the default when you juju deploy is to use charmhub. If you want to deploy from the charm store you can:

juju deploy cs:<name>

If you want to be explicit about deploying from charmhub you can

juju deploy ch:<name>

The output of juju status will also tell you where the deployed charms in a model came from :slight_smile:

Oh, I missed a bit - I don’t think you can directly correlate a charm revision with a git commit unless the author has chosen to version the charm with that info in the revision/version.

This isn’t officially supported, so we shouldn’t be document this. It’s a side-effect from how charm url parsing happens and that we use the same parsing logic in the CLI.

Thanks @simonrichardson

I was going to ask because the all the stable Openstack Bundles seem to be referencing cs:<name> method.

Could I ask on behalf of the Juju community if Canonical could provide some visibility of their intentions with Charmhub and Charmstore. Will one be deprecated in favor of the other or will they always be backward and forward compatible?

As @jnsgruk has pointed out, it is up to the individual charm development teams to provide information within the charm’s source uploaded into the stores to be able to relate a given build back to a repository commit.

I know of a couple of teams of charmers using a standard for encoding the repository and commit within their published charm sources.

For openstack-charmers, let’s use Keystone as an example:
Today, this URL shows that the current stable version of the cs:keystone charm is #323. This would show in juju status --format yaml as charm: cs:keystone-323.

If you then visit the charmstore, (or any deployed unit) and view the charm source, you’ll see a repo-info file within the charm’s top level directory which lists:

commit-sha-1: 8c9993e293c6c0a90f0177afed6d73c280a53b0b
commit-short: 8c9993e
branch: HEAD
remote: https://opendev.org/openstack/charm-keystone
info-generated: Mon May  3 12:22:29 UTC 2021
note: This file should exist only in a built or released charm artifact (not in the charm source code tree).

If you then visit the remote, you can find the commit in one of the stable branchs’ commit history. https://opendev.org/openstack/charm-keystone/commits/branch/stable/21.04

The Bootstack/Llama charms follow a similar style, such as:

where the “repo-info” file lists a branch that the charm was built from, and the version file contains the commit hash of the latest log entry/HEAD of the repository at build time.

All of those llama-charmers/bootstack-charmers charms are found at https://launchpad.net/charm-$CHARMNAME.

2 Likes

Excellent! That makes sense, this is what I was looking for. Thank you so much :slight_smile:

2 Likes