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

[Antonio Rosales]

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:
https://jujucharms.com/u/<id>/<bundle-name>/bundle/<revision>

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.

-thanks,
Antonio

[Cheryl Jennings (cherylj)]

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

[Antonio Rosales (arosales)]

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
https://jujucharms.com/u/<id>/<bundle-name>/bundle/<revision>

[Richard Harding (rharding)]

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:

mysql
mysql/trusty
mysql/15
mysql/trusty/15
u/rharding/msyql
u/rharding/mysql/xenial/18
u/rharding/mysql/18

cs:mysql
cs:mysql/trusty
cs:mysql/trusty/15
cs:u/rharding/mysql-scalable/33

and not documented but for those that need
cs:~rharding/mysql/trusty/15

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

Thoughts?

[Antonio Rosales (arosales)]

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.

-thanks,
Antonio

[Uros Jovanovic (uros-jovanovic)]

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:
rharding/mysql

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

[David Britton (dpb)]

See Also: https://github.com/CanonicalLtd/jujucharms.com/issues/322

[Christian Muirhead (2-xtian)]

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:

user/name/series/1
user/name/series
user/name/1
name/series/1
user/name
name/series
name/1
name

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)]

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.

[Christian Muirhead (2-xtian)]

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)]

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)]

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

[Anastasia (anastasia-macmood)]

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.

[Menno Finlay-Smits (menno.smits)]

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).

[Menno Finlay-Smits (menno.smits)]

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.

[Anastasia (anastasia-macmood)]

GUI issue on github: https://github.com/juju/juju-gui/issues/2625

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 5 years, so we're marking it Expired. If you believe this is incorrect, please update the status.