Juju 2.0 and local charm deployment
roger peppe
rogpeppe at gmail.com
Fri Mar 4 07:59:46 UTC 2016
On 4 March 2016 at 05:55, Ian Booth <ian.booth at canonical.com> wrote:
> Hi folks
>
> TL;DR we want to remove support for old style local charm repositories in Juju 2.0
>
> Hopefully everyone is aware that Juju 2.0 and the charm store will support
> multi-series charms. To recap, a multi-series charm is one which can declare
> that it supports more than just the one series; you no longer need to have a
> separate copy of the charm for precise vs trusty vs xenial. Note that all series
> must be for the same OS so you'll still need separate charm sources for Windows
> vs Ubuntu vs Centos.
>
> Here's a link to the release notes
> https://jujucharms.com/docs/devel/temp-release-notes#multi-series-charms
>
> Juju 2.0 will also support deploying bundles natively
> https://jujucharms.com/docs/devel/temp-release-notes#native-support-for-charm-bundles
>
> So, with multi-series charm support, local charm deployment is now also a lot
> easier. Back in Juju 1.x, to deploy local charms you needed to set up a
> so-called charm repository, with a proscribed directory layout. The directory
> layout has one directory per series.
>
> _ mycharms
> |_precise
> |_mysql
> |_trusty
> |_mysql
> |_bundle
> |_openstack
>
> You deployed using a local URL syntax:
>
> $ juju deploy --repository ~/mycharms local:trusty/mysql
>
> $ juju deploy --repository ~/mycharms local:bundle/openstack
>
> The above structure was fine for when charms were duplicated for each series.
> But one of the limitations is that you can't easily git checkout mycharm and
> deploy straight from the vcs source on disk.
>
> Juju 2.0 supports deploying charms and bundles straight from any directory,
> including where you've checked out your launchpad/github charm source.
>
> $ juju deploy ~/mygithubstuff/mysql
>
> $ juju deploy ~/mygithubstuff/openstack/bundle.yaml
>
> So the above combined with the consolidation of charms for many series into the
> one source tree means that the old local repo support is not needed.
>
> Will anyone complain if we drop local repos in Juju 2.0? Is there a use case
> where it's absolutely required to retain this?
Does this mean it won't be possible to deploy old single-series
charms with Juju without modifying metadata.yaml to add the supported
series?
More information about the Juju-dev
mailing list