juju deploy <bundle> is in a different form than jujucharms.com

Bug #1584193 reported by Antonio Rosales on 2016-05-20
This bug affects 4 people
Affects Status Importance Assigned to Milestone

Bug Description

When I deploy a non-promulgated charm from the charm store the path syntax is not the same as the charm store URLs.

The deployment syntax at the command line is:
 $ juju deploy ~<id>/bundle/<bundle-name>-<revision>

The URL is:

The deployment syntax given in the charm store is:
juju quickstart u/<id>/<bundle-name>/<revision-id>

Given it is not documented on the correct syntax to deploy non-promulgated bundles the user is easily confused as to which is the correct path syntax for deploying bundles, and finding the bundle in the charms store given bundle name and id.

The promulgated case is easy as the namespace is flat, however for development charms the ideal case would be the user knows the id and bundle name and thus can easily find the charm in the charm store via URL, and the path syntax at the command line given they are the same across command line, gui, and store URL.


Nate Finch (natefinch) on 2016-05-24
summary: - juju deploy <bundle> is in a different from than jujucharms.com
+ juju deploy <bundle> is in a different form than jujucharms.com
Cheryl Jennings (cherylj) wrote :

Once 2.0 is released, the deployment syntax should be updated in jujucharms.com to reference the new format.

Changed in juju-core:
status: New → Triaged
importance: Undecided → High
Antonio Rosales (arosales) wrote :

The areas users interface with juju are:

- jujucharms.com urls
- charm push/pull commands
- juju cli deploy commands
- juju gui URLs (similar to jujucharms.com)

Currently the patch to a charm or bundle are not the same across these areas. This can lead to confusion from a user experience perspective.

Ideally if a user knows the path that works in the same format where ever they have to type it in. So the following are all the same path syntax:

$ juju deploy ~<id>/bundle/<bundle-name>-<revision>
$ charm push . ~<id>/bundle/bundle-name

Richard Harding (rharding) wrote :

I think the current core format is incorrect.

~<id>/bundle/<bundle-name>-<revision> is not correct. This should have been updated to support the same that quickstart supported:

We should be allowing /u/username/item/revision with the default store implied.

And there should not be any /bundle in the paths at all.

We can keep the cs:~username/series/name-revision for compatibility, and we do need cs: to be allowed for future use cases.

Acceptable deployment paths:



and not documented but for those that need

Did we get http support for bundle urls like we had in quickstart? I don't recall where we fell on that.


Antonio Rosales (arosales) wrote :

Thanks for the comment Rick, idelly we keep the same path format for promulgated and unpromulgated charms and bundles across tools, juju-core, gui, and urls.


Uros Jovanovic (uros-jovanovic) wrote :

The last iteration of URLs has changed a bit and we're throwing the /u/ part away. So the new URLs should be of form :user/:name/:series/:revision .

Most of the deploys in charms will look like this:

So, you visit https://jujucharms.com/u/rharding/mysql, but "juju deploy rharding/mysql".

tags: added: 2.0 usability
Changed in juju-core:
milestone: none → 2.0.0
Changed in juju-core:
assignee: nobody → Richard Harding (rharding)
David Britton (dpb) wrote :
tags: added: landscape
affects: juju-core → juju
Changed in juju:
milestone: 2.0.0 → none
milestone: none → 2.0.0
Changed in juju:
milestone: 2.0.0 → 2.0-rc1
Changed in juju:
assignee: Richard Harding (rharding) → Alexis Bruemmer (alexis-bruemmer)
Changed in juju:
assignee: Alexis Bruemmer (alexis-bruemmer) → Christian Muirhead (2-xtian)
Christian Muirhead (2-xtian) wrote :

Just to check what I think I'm doing here...

We need to still accept the old-style URLs for people working from old examples or using scripts with those formats.

The desired :user/:name/:series/:rev has optional parts so it can be:


I think that's all of the possibilities, since name is required.

cs: will be allowed at the start of any of these. Also local:, I think?
(I'm ignoring the u/ prefix, #5 suggests that's not needed?)

Looking at the tests there are some existing old formats like series/name that should still be accepted but will conflict with the above ones. These can be distinguished using a fixed list of series.

There are also some test urls including the channel (which can only be development) - can those be specified in the new url format, or is it always specified in a separate --channel argument? Will "development" be changing to "edge" to match snaps?

From the tests it seems like there's a canonicalisation step for when the URL is echoed back to the user - I'll change this so that they're always echoed in the new format.

Christian Muirhead (2-xtian) wrote :

From discussing with urulama, hatch and frankban, the channel should be removed from the charm.URL struct - it's included at a higher level in the charmstore.CharmID structure instead.

Changed in juju:
status: Triaged → In Progress
Christian Muirhead (2-xtian) wrote :

I got rid of bundle as the series for bundle urls, but the charmstore sends back urls that look like cs:bundle/mediawiki-single-9 for bundles at the moment. I think I'll accept bundle in the series place but throw it away - does that sound reasonable?

Richard Harding (rharding) wrote :

Yes completely. We should also file a bug on the charmstore about it returning bundle in the urls @ https://github.com/juju/charmstore

Christian Muirhead (2-xtian) wrote :

PR for gopkg.in/juju/charm.v6-unstable: https://github.com/juju/charm/pull/221

Changed in juju:
milestone: 2.0-rc1 → 2.0-rc2
Curtis Hovey (sinzui) on 2016-09-29
Changed in juju:
milestone: 2.0-rc2 → none
Changed in juju:
milestone: none → 2.0.0
Changed in juju:
status: In Progress → Triaged
milestone: 2.0.0 → 2.1.0
assignee: Christian Muirhead (2-xtian) → nobody
Anastasia (anastasia-macmood) wrote :

This should be done in coordination with charm store ability to handle a new format.

Removing 2.1 milestone as we will not be addressing it in 2.1.

Changed in juju:
milestone: 2.1.0 → none

After much discussion in New Orleans it was decided that this would be handled within Juju. That is:

1. the Juju command line will accept u/:user/:name/:series/:rev style charm URLs (with all sensible abbreviations, as above) and cs:~:id/:series/:name-:rev style charm URLs. The preference will be the former with the latter removed from documentation.

2. Juju will normalise and store URLs to the old (cs:~...) form because that's what the charm store APIs currently accept.

3. Juju will convert charm URLs to the u/.../.../.../... form for output (e.g. status). Some care is required to cover cases where charm URLs are emitted in log or error messages.

Note that although there have been requests to remove the "u/" it can't go because it is needed to reliably disambiguate charm URLs in all cases.

This approach makes the CLI consistent with jujucharms.com, including the http://jujucharms.com/ URL suffixes for charms (e.g. https://jujucharms.com/u/lazypower/idlerpg/trusty/0).

The other thing that needs to change (outside of Juju) is the charm URL shown on a charm's page (above the Add to Model button). This is using the old style "cs:" format.

tags: added: charm charmers
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.