Juju 2.0 and local charm deployment

[Marco Ceppi]

Hi Ian,

We were just having a discussion about this for charm development. We
currently recommend the following setup for layered charms:

LAYER_PATH=$JUJU_REPOSITORY/layers
INTERFACE_PATH=$JUJU_REPOSITORY/interfaces

So you typically get

charms
├── deps
│   ├── interface
│   └── layer
├── interfaces
│   └── mongodb
├── layers
│   ├── mongodb
│   └── vpe-router
└── trusty
    └── vpe-router

We opened this https://github.com/juju/charm-tools/issues/115 to discuss
moving the built charm artifact outside of the series directory but we're
not sure where.

I had an entire counter point written as to why we should keep local: but I
just realized how easy it would be to type `juju deploy
$JUJU_REPOSITORY/build/charm_name`. This is way more explicit than a
local:charm_name with some magic environment variable lookup.

I'm a +1

How will bundles work which reference local charms? Will this work as
expected where nova-compute is a directory at the same level as a bundle
file?

```
series: trusty
services:
  nova-compute:
    charm: ./nova-compute
    num_units: 2
```

Marco

On Fri, Mar 4, 2016 at 12:55 AM 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?
>
>
>
>
>
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160304/760c2ea2/attachment.html>