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
juju deploy cs:redis
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 (
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.
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 http://juju.is/redis
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
You can do the versioning in the URL, to match the origin CharmStore URL.
juju deploy https://ubuntu.com/u/jameinel/ubuntu-lite/xenial/7
juju deploy cs:~jameinel/xenial/ubuntu-lite-7
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
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!).