Deploy command: charmhub

Currently, the deploy command in Juju is being updated to take into account the new charm repository/store called the CharmHub. One of the issues that will require ironing out is the issue around deploying a charm from a UX perspective. It might help if I explain what Juju can do when you deploy with just the charm name and ignoring all the other flags for customisation.

Note: I’m omitting bundles for the moment, as they act in almost the same way.



The basic standard one, just deploy with the CharmStore prefix (cs), nothing special does exactly what you thing and grabs the latest redis

juju deploy cs:redis

Charmstore versions

Additionally to the standard CharmStore, you can also pass optional extras to target specific versions of the charm. For example, you can pass in a user (jameinel), the series you want (bionic) and the charm name (ubuntu-lite) and finally the target revision (7).

juju deploy cs:~jameinel/bionic/ubuntu-lite-7


Accompanying the CharmStore declarations you can also identify a charm via your local filesystem. Super handy if you’re developing locally or are air-gapped.

juju deploy ./charm


All of these are obvious well-trodden axioms from the Juju documentation/tutorial perspective. Yet there are some declarations for deploy that can be used that are less utilised, but are valid.

Charmstore without a prefix

This one is used, especially by me when testing, but is always inferred by the charm URL parsing library to always means CharmStore. If the cs: is missing, it will always prefix the charm name with it.

For example juju deploy redis becomes juju deploy cs:redis, excellent!

Depending on your shell (not in zsh, you need to quote the charm URL) you should also be able to do juju deploy ~jameinel/xenial/ubuntu-lite-7.

Charmstore using a URL

This one was surprising to me, but you can also juju deploy with a fully-qualified URL. The domain in question doesn’t matter at all, it just re-writes the URL to something that resembles the V1 (let’s call the fully-qualified URL V2) charm URL.

juju deploy

Interestingly https also works, but it must be said, no network connection is used at this point, we’re just re-writing the URL to the V1 URL. So it becomes cs:redis.

You can do the versioning in the URL, to match the origin CharmStore URL.

juju deploy

Which becomes juju deploy cs:~jameinel/xenial/ubuntu-lite-7


Local prefix

Interestingly the charm URL library supports the addition of using a prefix (local:), but unfortunately, the charm URL doesn’t support the parsing of the URL if it has the local: prefix.

juju deploy local:~/some/charm # doesn't work!


So what does this have to do with the CharmHub?

To transition over to the CharmHub and to allow for the CharmStore and the local charm URLs to co-exist, we want the user to have the intention of stating that they intend to target a particular store.

Either that’s with a feature flag, that we turn on and state that all non-local charm URLs will be pushed towards the CharmHub, or we state that anything without a cs: prefix is intended for the CharmHub. The downside to the latter is that we prevent some of the above from working and that might be a breaking change for some users of the CLI (and I fall into that category!).

1 Like

Perhaps have a means to add named prefix aliases in some juju client database which would allow a user to add sources, something like :

juju store-alias mystore
juju deploy mystore:foo/bar

Then cs cloud be a protected alias along with local etc.